This patch is the initial support for the Local Exec Thread Local
Storage model to produce code sequence and relocations correct
to the ABI for the model when using PC relative memory operations.
Details
- Reviewers
stefanp nemanjai NeHuang kamaub - Group Reviewers
Restricted Project - Commits
- rGc0f199e5667a: [PowerPC] Implement Thread Local Storage Support for Local Exec
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Target/PowerPC/PPCISelLowering.h | ||
---|---|---|
444 | I think this might make more sense: /// TLS_LOCAL_EXEC_MAT_ADDR = Materialize an address for TLS global address /// when using local exec access models, and when prefixed instructions are /// available. This is used with ADD_TLS to produce an add like PADDI. | |
llvm/test/CodeGen/PowerPC/pcrel-tls-local-exec.ll | ||
10 | nit: for the Local Exec TLS Model. | |
llvm/test/MC/PowerPC/pcrel-tls-local-exec-address-load-reloc.s | ||
8 | nit: with the address loaded. |
Only minor nits form me.
LGTM.
llvm/test/CodeGen/PowerPC/pcrel-tls-local-exec.ll | ||
---|---|---|
6 | I think you are missing -enable-ppc-pcrel-tls here and in the command above. | |
llvm/test/MC/PowerPC/pcrel-tls-local-exec-address-load-reloc.s | ||
14 | nit: | |
llvm/test/MC/PowerPC/pcrel-tls-local-exec-value-load-reloc.s | ||
14 | nit: |
Also, please add a test where the offset is not zero.
So the assembly would be for example:
paddi 3, 13, x@TPREL+8, 0
Sorry to have approved it and then requested changes. :(
llvm/test/CodeGen/PowerPC/pcrel-tls-local-exec.ll | ||
---|---|---|
31 | I just realized this issue this morning. paddi r3, r13, x@TPREL, 0 lwz r3, <OFFSET>(r3) we can probably generate: plwz r3, x@TPREL+<OFFSET>(r13) Where <OFFSET> is just some value. |
llvm/test/CodeGen/PowerPC/pcrel-tls-local-exec.ll | ||
---|---|---|
31 | After an internal discussion it has been decided that we can leave this improvement for another patch. At this point I would say that we should just extend the test case to include offsets but not implement the merging of those two instructions. |
llvm/lib/Target/PowerPC/MCTargetDesc/PPCELFObjectWriter.cpp | ||
---|---|---|
424 | This switch was originally commit in rGbd2068031121adf5a0e28d9306a1741d6f0bbd87 but was reverted by rGce1e4853b5a15d679bd662ac5777a2390daf0391 because of failures in Release+Asserts mode with an assert. So rG97470897c436a6a5d682fb8ab296d0bcdc6e32a4 committed it as an report_fatal_error() to resolve the problem. I am not sure that assert() won't cause a similar problem as llvm_unreable() since we replaced llvm_unreachable() with report_fatal_error() for similar reason to why they suggest using assert() with llvm_unreachable() in
I could be wrong though, should we still replace it with an assert? I think the answer to your question is yes, it was reachable. |
Added test case for non-zero offset, added a few flags to the RUN lines and removed some unecessary comments.
This mostly LGTM.
From my perspective you can add no-show-raw-insn on commit.
llvm/test/CodeGen/PowerPC/pcrel-tls-local-exec.ll | ||
---|---|---|
7 | I agree. Please use no-show-raw-insn! | |
66 | Thank you for adding this test. |
Is this unreachable? If yes, assert may be better