This patch introduces TLS (Thread-Local Storage) support to the LLVM m68k backend.
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Target/M68k/M68kISelLowering.cpp | ||
---|---|---|
1432 | None of this is m68k-specific (with the exception of using unsigned instead of unsigned long), these long comments are just a repeat of how ELF TLS works in general. I don't think they belong here. | |
1453 | Skip the custom node / pseudo and use LowerCallTo? | |
1500 | Skip the custom node / pseudo and use LowerCallTo? | |
1517 | Ditto | |
llvm/lib/Target/M68k/M68kInstrArithmetic.td | ||
317 | Presumably because you're abusing M68kISD::ADD, which has type MxSDT_BiArithCCROut: // RES, CCR <- op LHS, RHS def MxSDT_BiArithCCROut : SDTypeProfile<2, 2, [ /* RES */ SDTCisInt<0>, /* CCR */ SDTCisVT<1, i8>, /* LHS */ SDTCisSameAs<0, 2>, /* RHS */ SDTCisSameAs<0, 3> ]>; You're using it as if it only had one i32 result, but it's iN,i8 = M68kISD::ADD iN, iN. Since you don't care about CCR here presumably you can just use a normal ISD::ADD instead, but if you do then use the right types. | |
llvm/lib/Target/M68k/M68kInstrCompiler.td | ||
133 ↗ | (On Diff #501464) | Why the blank lines? |
134 ↗ | (On Diff #501464) | : needs a space |
134 ↗ | (On Diff #501464) | Surely this function call clobbers all call-clobbered registers like any other architecture's __tls_get_addr? Glancing at glibc, the version used for statically-linked binaries is implemented in C so won't be doing anything special to preserve registers. |
135 ↗ | (On Diff #501464) | AFAICT this is also implemented in C and thus clobbers the usual call-clobbered registers. |
llvm/lib/Target/M68k/MCTargetDesc/M68kBaseInfo.h | ||
161 | Comment | |
llvm/lib/Target/M68k/MCTargetDesc/M68kELFObjectWriter.cpp | ||
74 | These should be deindented, but the other variants don't do this so now it's all an inconsistent mess. | |
llvm/test/CodeGen/M68k/TLS/tlsie.ll | ||
20 | These shouldn't be in UTC tests. Besides, it's implied by the assembly, and if you want to test the relocation emission then write MC tests for that part. |
llvm/lib/Target/M68k/M68kISelLowering.cpp | ||
---|---|---|
1432 | The code generation snippet for TLS is complicated. These comments help clarify the details and may be helpful for me or others who come to maintain it in the future. |
llvm/lib/Target/M68k/M68kISelLowering.cpp | ||
---|---|---|
1432 | *The details of how TLS works are complex* |
llvm/lib/Target/M68k/M68kISelLowering.cpp | ||
---|---|---|
1432 | And those who want the details can go read Drepper's TLS document. All these comments are just noise; for anyone who knows how TLS works (which, if you're reading/writing this part of the compiler, you should) it serves no purpose and makes the code harder to read, and for anyone who doesn't they should go read the actual document. Or just read the code, it's not all that complicated, it's clearly just doing __tls_get_addr(GOT + sym@TLSGD), __tls_get_addr(GOT + sym@TLSLDM) + sym@TLSLD, __m68k_read_tp() + *(GOT + sym@GOTTPOFF) and __m68k_read_tp() + sym@TPOFF. If every common bit of lowering were documented like these then the backends would be absurdly large, but we don't, we generally only document places where there are unusual or complicated things going on. |
Do we have any more issues left to address? Seems like all comments have been marked as "done".
Some minor comments
llvm/lib/Target/M68k/M68kISelLowering.cpp | ||
---|---|---|
1522 | Not a useful error message | |
llvm/test/CodeGen/M68k/TLS/tlsgd.ll | ||
12 | Best to use nounwind in tests where you don't care about CFI but get them due to function calls | |
llvm/test/CodeGen/M68k/TLS/tlsie.ll | ||
11 | Why do we need the stack adjustment? We're not passing any arguments to __m68k_read_tp. Or is this some stack alignment issue to compensate for the implicit push of the return address? | |
llvm/test/CodeGen/M68k/TLS/tlsld.ll | ||
9 | Teach ASM_FUNCTION_M68K_RE in UpdateTestChecks to filter these | |
llvm/test/CodeGen/M68k/TLS/tlsle.ll | ||
4–5 |
llvm/test/CodeGen/M68k/TLS/tlsie.ll | ||
---|---|---|
11 | This adjustment is the consequence of M68kSubtarget::stackAlignment [0] The comment says: /// The minimum alignment known to hold of the stack frame on /// entry to the function and which must be maintained by every function. unsigned stackAlignment = 8; I don't know why it is set to 8 as the ABI only requires 2. @myhsu do you have any clue ? [0] https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/M68k/M68kSubtarget.h#L73 |
llvm/test/CodeGen/M68k/TLS/tlsie.ll | ||
---|---|---|
11 |
I'm not sure why it was assigned 8 bytes even after reading the change log. But I'm pretty sure we want to change that (in another patch, of course) to the minimum alignment, which is 2 bytes. |
One nit to fix when committing, otherwise nothing jumps out as wrong to me. Someone else with m68k knowledge should give it a once-over.
llvm/utils/UpdateTestChecks/asm.py | ||
---|---|---|
67 ↗ | (On Diff #519017) | “funciton” in the comment, and should be a separate commit |
The critial C++ part has been well reviewed by jrtc27 and RKSimon. I think the last step would be to verify the correctness of the genenrated m68k assembly. @glaubitz @myhsu could you help on this ? If the generated assembly is ok then I think we can give it a go. @glaubitz I have assigned you as a reviewer so you can decide it on you own.
The patch set allowed me to compile C++ that was making use of TLS and fixed a bug that I originally ran into. So I think it's good to land.
(style) Avoid auto - use SDValue