[PATCH] D61907: [RISCV] Leave pcrel_hi/pcrel_lo fixup pairs unresolved
Lewis Revill via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Jul 12 02:28:50 PDT 2019
lewis-revill marked an inline comment as done.
lewis-revill added inline comments.
================
Comment at: test/MC/RISCV/linker-relaxation.s:125
addi t1, t1, %pcrel_lo(2b)
-# NORELAX-RELOC-NOT: R_RISCV_PCREL_LO12_I
+# NORELAX-RELOC: R_RISCV_PCREL_LO12_I bar 0x4
# NORELAX-RELOC-NOT: R_RISCV_RELAX
----------------
jrtc27 wrote:
> asb wrote:
> > asb wrote:
> > > Shouldn't be this be `.Ltmp1 0x0` just like in the RELAX-RELOC case?
> > Hi Lewis, did you have any thoughts on this?
> Yes, it should be. It's because `RISCVMCExpr::evaluateAsRelocatableImpl` evaluates it fully to the indirected symbol since `RAB.willForceRelocations` is false, unlike the RELAX-RELOC case.
So, if I understand correctly, `evaluatePCRelLo` will do it's work regardless of whether the relocation is actually evaluated, it just uses this 'best guess' function `RAB.willForceRelocations` and some of its own logic. Is this not a bug regardless of this patch? Are we relying on the logic in `shouldForceRelocations` and `evaluatePCRelLo` producing the exact same answer?
Are there uses of `evaluatePCRelLo` that aren't part of this assembler pipeline? Because if not then doesn't that imply that for this patch the entire `evaluatePCRelLo` functionality would be completely removed?
Repository:
rL LLVM
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D61907/new/
https://reviews.llvm.org/D61907
More information about the llvm-commits
mailing list