This patch allows generating TLS variables in assembly files on AIX.
Initialized and external uninitialized variables are generated with the
.csect pseudo-op and local uninitialized variables are generated with
the .comm/.lcomm pseudo-ops. The patch also adds a check to
explicitly say that TLS is not yet supported on AIX.
Details
- Reviewers
nemanjai stefanp sfertile jasonliu daltenty hubert.reinterpretcast bsaleil - Group Reviewers
Restricted Project - Commits
- rG1756b2adc9c1: [AIX][TLS] Generate TLS variables in assembly files
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Event Timeline
llvm/lib/MC/MCSectionXCOFF.cpp | ||
---|---|---|
41 | Would it be helpful to mention in the comment that the initialized data are generated with the .csect pseudo-op? |
llvm/test/CodeGen/PowerPC/aix-tls-variables.ll | ||
---|---|---|
22 | It's out of scope for this patch, but there is definitely a delta here between how we emit thread-local (to .tbss) and non-thread local uninitialized data (i.e. to regular data section instead of bss) beyond just the thread-local part. Not sure if that's something we should address. |
llvm/test/CodeGen/PowerPC/aix-tls-variables.ll | ||
---|---|---|
22 | As a follow on, as discussed offline, using common for uninitialized data may have linkage considerations. We should consider if this applies to .tbss data as well before using .comm directives. |
LGTM. Please wait until David has given it the OK too though.
llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp | ||
---|---|---|
2164 | Maybe if you add a comment before : XCOFF::XMC_UL; clang-format will end up keeping a similar layout to what you already have. If not we should follow clang-format even though its inferior in this instance 😦 . |
llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp | ||
---|---|---|
2068 | !GV->hasExternalLinkage() doesn't actually imply the symbol is local, we probably want something more like isLocalLinkage() We should add some testcases for other non-local linkages like weak. |
@daltenty As per discussion offline
- Update the code to check isLocalLinkage
- More test coverage for weak linkage and update test case
- clangformat the patch
- Fix the missing directives printing for weak linkage.
- Update the test case accordingly.
llvm/test/CodeGen/PowerPC/aix-tls-variables.ll | ||
---|---|---|
123 | Yes, updated. |
llvm/test/CodeGen/PowerPC/aix-tls-variables.ll | ||
---|---|---|
112 | it would be easier to verify these checks if they were placed right before the declaration of the variable they are checking. Similar to what is done when we write checks for multiple functions. |
llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp | ||
---|---|---|
2163 | Remove the second sentence here. Where other things get mapped depends on data-sections and other factors that aren't relevant to this block. | |
2165 | I'm thinking this condition is important enough for us to provide a convince function. Something like isEligibleForCommonCsect and use it in the other three places where this exact condition should appear. | |
llvm/lib/MC/MCObjectFileInfo.cpp | ||
886 | We should initialize and use the TLSBSSSection where appropriate. | |
llvm/test/CodeGen/PowerPC/aix-tls-variables.ll | ||
53 | Should probably be UL, since this is uninitialized |
llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp | ||
---|---|---|
2227 | We should have another case for Kind.isThreadBSS, where we should probably use either a csect with XMC_UL or TLSBSSSection depending on TM.getDataSections() |
llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp | ||
---|---|---|
2227 | Agree, we should add the coverage for non-initialized cases using Kind.isThreadBSS() | |
llvm/lib/MC/MCSectionXCOFF.cpp | ||
71 | We would also need isEligibleForCommonCsect check to be aligned here. | |
83 | We need to cover the other TLS scenario here which is not eligible for commonCsect - to print CsectDirective. | |
llvm/test/CodeGen/PowerPC/aix-tls-variables.ll | ||
112 | Sure. Will also alternate the test cases as below |
LGTM with minor comment and naming fixes
llvm/test/CodeGen/PowerPC/aix-tls-variables-ppc32.ll | ||
---|---|---|
23 ↗ | (On Diff #327424) | As discussed offline, we should rename these from TL/UL to something a bit more descriptive |
llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp | ||
---|---|---|
2236 | As we recently found out XCOFF::XMC_UL implies XCOFF::XTY_CM in the assembler. Since we may have external linkage symbols inside this section, we cannot use XCOFF::XTY_CM, so we must use XMC_TL here. | |
2239 | Same as earlier, we cannot emit this to TLSBSSSection. Any external linkage symbols inside it will make the assembler unhappy. | |
llvm/lib/MC/MCObjectFileInfo.cpp | ||
887 | Based on testing XMC_UL implies XMC_CM so this isn't actually a legal combination. We should probably add an assert to that extent in a follow on patch. Also, we can't actually use this section as is in this patch anymore, so I suggest we leave out the initialization and move it to a follow on patch. |
llvm/lib/MC/MCSectionXCOFF.cpp | ||
---|---|---|
41 | here should be initialized TLS data |
Addressed the review comments to
- Fix the storaging map class for zero-initialized TLS data with external/weak linkage and update the test cases.
- Renaming the test cases with proper description (zero-initialized, val-initialized and uninitialized
- Add more comments for the implementation and correct some minors.
Remove the second sentence here. Where other things get mapped depends on data-sections and other factors that aren't relevant to this block.