AMDGPUAsmPrinter, ARMAsmPrinter, MipsAsmPrinter, NVPTXAsmPrinter, PPCLinuxAsmPrinter, and XCoreAsmPrinter derive EmitFunctionEntryLabel() and have custom logic there. PPCAIX should not be an exception.
Details
- Reviewers
Xiangling_L jasonliu hubert.reinterpretcast sfertile stefanp xingxue - Group Reviewers
Restricted Project
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Unit tests: pass. 61999 tests passed, 0 failed and 783 were skipped.
clang-tidy: unknown.
clang-format: pass.
Build artifacts: diff.json, clang-format.patch, CMakeCache.txt, console-log.txt, test-results.xml
Thank you for mentioning this issue, the reason why we added MAI->needsFunctionDescriptors() are as follows:
- On AIX, function descriptor and function entry point are totally two different things, we are emitting two distinct symbols. Function descriptor symbol has no relation to function entry point symbol other than referencing its address. The way ELFV1 ABI handles descriptors(with the entry point being a local symbol, and the descriptor being the global symbol) it kinda squeaks into the definition of EmitFunctionEntryLabel().
- From the description of the MCAsmInfo class:
This class is intended to be used as a base class for asm properties and features specific to the target.
Adding a hook to MAI for descriptors and querying that is a valid way to represent this. That said, there are other places in this file that change the codegen based on explicit check of either the OS or the binary format. Besides, why we prefer the way my previous patch is doing is also because needsFunctionDescriptors() makes the code self-documenting as opposed to getTargetTriple().isOSAIX().
For AMDGPU, ARM, Mips and XCore the AsmPrinter is doing something directly related to the entry label/function symbol in the hook: like setting its type or emitting directives that directly affect the label. PowerPC32 and ELFV2 PowerPC64 embed some data just before the entry label but still in the same section. PowerPC AIX and PowerPC ELFV1 differ in that they create and emit a second symbol into a different section, that is distinct from the functions entry label. I can understand why the ELFV1 implementation chose to do it in the EmitEntryLabel callback at the time: it works and its non-intrusive, but I think the implementation approach taken in D66742 is superior.
I don't think its all that difficult to find out this is AIX specific. A quick grep for NeedsFunctionDescriptors will show its the only platform to set it to true, and I agree with @Xiangling_L reasoning above for why a new MCAsmInfo hook was used over directly checking if the OS is AIX. I think we have failed with describing what descriptors are and who they are useful to in the code where MAI->needsFunctionDescriptors() is used. I am happy to post a patch to fix that. I think rather then removing the abstraction though, it would be better to migrate the PowerPC ELFV1 abi to using it as well, although it might take some tweaks because the ELF and XCOFF implementations differ slightly.