Is jalr with rs1=x0 inferable?

[pdonahue-ventana]

Section 4.1.1 says:

For the purposes of this specification, the following strict definition applies:
If the target of a jump is supplied via a constant embedded within the jump opcode, it is classified
as inferable.

By my reading, the only jump in the base architecture that fits that description is JAL. Then JALR is later described as inferable if it follows a LUI, C.LUI, or AUIPC. However, the pseudocode has:

# Determine if instruction is an inferable jump #
function is_inferable_jump (instr)

  if ((instr.opcode == JAL)   or
      (instr.opcode == C.JAL) or
      (instr.opcode == C.J)   or
      (instr.opcode == JALR and instr.rs1 == 0))
    return TRUE

So does "constant" include the rs1 field? (I see how a jump to x0 +/- 4KB could be inferable, though this seems like a weird optimization in real life.)

[IainCRobertson]

Paul, That's a good point. The intent when I wrote that sentence in 4.1.1 was to convey the point that if the target of the jump can be fully deduced from the source code alone then the jump is inferable. The pseudo-code reflects that intent, as the fact that x0 is always 0 means that the target of a JALR with rs1 = 0 is inferable. However, as written the text in 4.1.1 does not include this special case. This leaves us with a bit of a dilemma. On the one hand we could clarify 4.1.1 to include this special case. However, the current text is very clear and unambiguous, and as such changing it to include the special case could be considered a normative change. I The pseudo-code on the other hand is informative only, and furthermore, changes there would only impact software. As you point out, the chances of this optimization occurring are pretty small. But if it did occur then the HW and the decoder need to use the same definition of inferable in order for decoding to work properly. And I think it's far more likely that any existing hart implementations will have used the definition from 4.1.1 (which is after all normative) than the pseudo code. Based on the above my proposal would be to take the special case out of the pseudo-code and leave 4.1.1 as-is. Iain From: Paul Donahue ***@***.***> Sent: 06 January 2025 19:02 To: riscv-non-isa/riscv-trace-spec ***@***.***> Cc: Subscribed ***@***.***> Subject: [riscv-non-isa/riscv-trace-spec] Is jalr with rs1=x0 inferable? (Issue #188) Section 4.1.1 says: For the purposes of this specification, the following strict definition applies: If the target of a jump is supplied via a constant embedded within the jump opcode, it is classified as inferable. By my reading, the only jump in the base architecture that fits that description is JAL. Then JALR is later described as inferable if it follows a LUI, C.LUI, or AUIPC. However, the pseudocode<https://github.com/riscv-non-isa/riscv-trace-spec/blob/main/decoder.adoc?plain=1#L221> has: # Determine if instruction is an inferable jump # function is_inferable_jump (instr) if ((instr.opcode == JAL) or (instr.opcode == C.JAL) or (instr.opcode == C.J) or (instr.opcode == JALR and instr.rs1 == 0)) return TRUE So does "constant" include the rs1 field? (I see how a jump to x0 +/- 4KB could be inferable, though this seems like a weird optimization in real life.) - Reply to this email directly, view it on GitHub<#188>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ALQOPSR7DURRM3TY5GC4PGT2JLHKBAVCNFSM6AAAAABUWF3ONOVHI2DSMVQWIX3LMV43ASLTON2WKOZSG43TCMRVHE3TGOI>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.******@***.***>>

[pdonahue-ventana]

I'm happy with that resolution.