This is an archive of the discontinued LLVM Phabricator instance.

[AIX] Replace EmitFunctionDescriptor with EmitFunctionEntryLabel() and delete needsFunctionDescriptors()
AbandonedPublic

Authored by MaskRay on Jan 18 2020, 4:38 PM.

Details

Reviewers
Xiangling_L
jasonliu
hubert.reinterpretcast
sfertile
stefanp
xingxue
Group Reviewers
Restricted Project
Summary

AMDGPUAsmPrinter, ARMAsmPrinter, MipsAsmPrinter, NVPTXAsmPrinter, PPCLinuxAsmPrinter, and XCoreAsmPrinter derive EmitFunctionEntryLabel() and have custom logic there. PPCAIX should not be an exception.

Diff Detail

Event Timeline

MaskRay created this revision.Jan 18 2020, 4:38 PM
Herald added a project: Restricted Project. · View Herald TranscriptJan 18 2020, 4:38 PM
MaskRay added a reviewer: Restricted Project.Jan 18 2020, 4:46 PM

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

Xiangling_L added a comment.EditedJan 20 2020, 7:19 AM

Thank you for mentioning this issue, the reason why we added MAI->needsFunctionDescriptors() are as follows:

  1. 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().
  1. 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().

In D66724, @MaskRay wrote:

I am not sure this "pushing past the limits of what the comment intended" was a strong argument for EmitFunctionDescriptor and needsFunctionDescriptors(). This is the way all other targets (AMDGPUAsmPrinter, ARMAsmPrinter, MipsAsmPrinter, NVPTXAsmPrinter, PPCLinuxAsmPrinter, and XCoreAsmPrinter) handle things. AIX does not have to be an exception.

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.

In D66724, @MaskRay wrote:

If needsFunctionDescriptors() is really AIX specific, I feel that TM.getTargetTriple().isOSAIX() will made a casual reader's life simpler. I did not know what function descriptors are and jumped over hoops to know this is really AIX specific. We can add the abstraction when more targets use it.

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.

MaskRay abandoned this revision.Jan 20 2020, 3:02 PM