Such symbols may be undefined at link time and thus resolve to 0, which
may be further than 2GiB away from PC, causing the immediate to be out
of range for PC-relative addressing. Using the GOT avoids this, and is
the approach taken by AArch64.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Target/RISCV/RISCVISelLowering.cpp | ||
---|---|---|
5233 | Change the argument. The variable can be removed. |
llvm/lib/Target/RISCV/RISCVISelLowering.cpp | ||
---|---|---|
5233 | Well you could say the same about Ty and IsLocal, they're both used exactly once so could be inlined, but IMO this keeps it more readable; nested function calls can get rather messy. |
llvm/lib/Target/RISCV/RISCVISelLowering.cpp | ||
---|---|---|
5233 | IsExternWeak is a good candidate. Its expr isn't very long. IsLocal is long and leaving it as is is fine. |
It looks like this has been approved for roughly a year and yet hasn't landed. Could we get this rebased and landed?
I'm aware this is somewhat still an area of controversy in the psABI, but the GOT based lowering here is conservatively correct regardless of outcome there. If we do settle on the GOT required answer - which looks likely, having this in as early as possible should help minimize migration pain. If we decide on requiring the relaxation, this change does no harm and could be reverted later if desired. The only reason I can see to hold this if we think there's a potential performance concern, but if so, we really need to know that for the psABI discussion and exposing it by landing this and seeing what falls out seems like still a net win.
There is no controversy. The behavior on most targets for external weak symbol is to use GOT.
I was holding off until the LGA pseudo was accepted in riscv-asm-manual, which seems to finally have happened in March
LGTM if everyone else is happy with it.
Would it make sense to backport this patch series to the 15 release? I'd quite like to be able to make use of this.
Consider adding Link: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/201
This properly addresses the root cause leading to https://github.com/riscv-non-isa/riscv-elf-psabi-doc/issues/197
I think all questions and review comments were resolved - anything you can see blocking this now @jrtc27?
I think it just didn’t get landed because it needs rebasing to adapt to more recent changes in L(L)A handling. Will try and update in the coming days.
Looks great!
llvm/lib/Target/RISCV/RISCVISelLowering.cpp | ||
---|---|---|
5207 | Extern weak symbols, if unresolved, must be addressed indirectly ... extern_weak is the IR representation related to the current module. Another TU may provide a definition. The original sentence is imprecise. |
llvm/lib/Target/RISCV/RISCVISelLowering.cpp | ||
---|---|---|
5207 | Hmm, better wording may be that "An unresolved undefined weak symbol has a value of zero, which may not be within +-2GiB of PC. Use a GOT-generating code sequence so that the zero address is representable." This may feel verbose. Feel free to simplify. |
clang-format not found in user’s local PATH; not linting file.