[PATCH] D105528: [RuntimeDyldChecker] Support offset in decode_operand expr

[Jessica Clarke via Phabricator via llvm-commits]

jrtc27 added inline comments.


================
Comment at: llvm/test/ExecutionEngine/JITLink/RISCV/ELF_pc_indirect.s:22
 # jitlink-check: decode_operand(test_pcrel32, 1) = ((named_data - test_pcrel32) + 0x800) >> 12
+# jitlink-check: decode_operand(test_pcrel32+4, 2) = (named_data - test_pcrel32) - (((named_data - test_pcrel32 + 0x800) & 0xfffff000))
         .globl  test_pcrel32
----------------
StephenFan wrote:
> jrtc27 wrote:
> > This is just `(named_data - test_pcrel32) & 0xfff` sign-extended from 12 to 64 bits. The + 0x800 for the HI is to compensate for the sign extension for the LO, feeding it back into the LO calculation is backwards and results in circular reasoning.
> > This is just `(named_data - test_pcrel32) & 0xfff` sign-extended from 12 to 64 bits. The + 0x800 for the HI is to compensate for the sign extension for the LO, feeding it back into the LO calculation is backwards and results in circular reasoning.
> 
> @jrtc27 Thank you for reminding me! You're right! By thinking again,  here is my understanding:
> 
>  If the pc relative value is 0x00001fff, if don't add 0x800, then the value will be split to high 20bits(`0x00001`) and low 12bits(`0xfff`). However, the low 12bits will be considered as a signed number. so the MSB of 0xfff which originally represent `2^11` now changed to `-2^11`. The difference is `2^12`. So we need to add `0x800`  to compensate the difference. Are there any errors in my understanding?
2^12 is 0x1000. You're conditionally adding 0x1000 to the hi20 value based on whether the 12th bit is set which, given hi20 throws away the low 12 bits, is the same as unconditionally adding 0x800 and relying on the carry bit of 0x800 + 0x800 to give you 0x1000.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D105528/new/

https://reviews.llvm.org/D105528