This is an archive of the discontinued LLVM Phabricator instance.

[m68k] Add TLS Support
ClosedPublic

Authored by 0x59616e on Feb 27 2023, 9:21 PM.

Details

Summary

This patch introduces TLS (Thread-Local Storage) support to the LLVM m68k backend.

Diff Detail

Event Timeline

0x59616e created this revision.Feb 27 2023, 9:21 PM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 27 2023, 9:21 PM
Herald added a subscriber: hiraditya. · View Herald Transcript
0x59616e requested review of this revision.Feb 27 2023, 9:21 PM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 27 2023, 9:21 PM
myhsu added a reviewer: myhsu.Feb 28 2023, 9:35 AM
0x59616e edited the summary of this revision. (Show Details)Feb 28 2023, 4:05 PM
0x59616e added reviewers: RKSimon, jrtc27, glaubitz, ricky26.
0x59616e planned changes to this revision.Feb 28 2023, 9:39 PM

A few minor adjustments are required.

0x59616e updated this revision to Diff 501464.Mar 1 2023, 5:05 AM

Add some comments

jrtc27 added inline comments.Mar 1 2023, 5:36 AM
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.

0x59616e marked an inline comment as done.Mar 1 2023, 7:13 AM
0x59616e added inline comments.
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.

0x59616e marked an inline comment as done.Mar 1 2023, 7:15 AM
0x59616e added inline comments.
llvm/lib/Target/M68k/M68kISelLowering.cpp
1432

*The details of how TLS works are complex*

jrtc27 added inline comments.Mar 1 2023, 7:58 AM
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.

This comment was removed by 0x59616e.
0x59616e updated this revision to Diff 508508.Mar 27 2023, 12:43 AM
0x59616e marked 12 inline comments as done.

address feedbacks

Do we have any more issues left to address? Seems like all comments have been marked as "done".

jrtc27 added a comment.May 1 2023, 2:49 PM

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
0x59616e updated this revision to Diff 519017.May 3 2023, 2:17 AM
0x59616e marked 4 inline comments as done.

address feedbacks

0x59616e edited the summary of this revision. (Show Details)May 3 2023, 2:18 AM
0x59616e added inline comments.
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

myhsu added inline comments.May 5 2023, 2:11 PM
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

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.

Any updates on this?

No updates here. Ready for review.

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

RKSimon added inline comments.May 25 2023, 2:51 AM
llvm/lib/Target/M68k/M68kISelDAGToDAG.cpp
670

(style) Avoid auto - use SDValue

672

(style) MachineSDNode *Res

0x59616e updated this revision to Diff 525913.May 25 2023, 7:31 PM

Address feedbacks

I guess we're good to go now, aren't we?

ping. Any suggestion ?

0x59616e added a comment.EditedJun 2 2023, 2:09 AM

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 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.

glaubitz accepted this revision.Jun 3 2023, 1:59 AM
This revision is now accepted and ready to land.Jun 3 2023, 1:59 AM
This revision was automatically updated to reflect the committed changes.