[AIX][XCOFF]emit extern linkage for the llvm intrinsic symbol

[DiggerLin]

Summary

1. when we call memset, memcopy,memmove etc(this are llvm intrinsic function) in the c source code. the llvm will generate IR

like call call void @llvm.memset.p0i8.i32(i8* align 4 bitcast (%struct.S* @s to i8*), i8 %1, i32 %2, i1 false)
for c source code
bash> cat test_memset.call

struct S{
 int a;
 int b;
};
extern struct  S s;
void bar() {
  memset(&s, s.b, s.b);
}

like

%struct.S = type { i32, i32 }
@s = external global %struct.S, align 4
; Function Attrs: noinline nounwind optnone
define void @bar() #0 {
entry:
  %0 = load i32, i32* getelementptr inbounds (%struct.S, %struct.S* @s, i32 0, i32 1), align 4
  %1 = trunc i32 %0 to i8
  %2 = load i32, i32* getelementptr inbounds (%struct.S, %struct.S* @s, i32 0, i32 1), align 4
  call void @llvm.memset.p0i8.i32(i8* align 4 bitcast (%struct.S* @s to i8*), i8 %1, i32 %2, i1 false)
  ret void
}
declare void @llvm.memset.p0i8.i32(i8* nocapture writeonly, i8, i32, i1 immarg) #1

If we want to let the aix as assembly compile pass without -u
it need to has following assembly code.
.extern .memset
(we do not output extern linkage for llvm instrinsic function.
even if we output the extern linkage for llvm intrinsic function, we should not out .extern llvm.memset.p0i8.i32,
instead of we should emit .extern memset)

2. for other llvm buildin function floatdidf . even if we do not call these function floatdidf in the c source code(the generated IR also do not the call __floatdidf . the function call

was generated in the LLVM optimized.
the function is not in the functions list of Module, but we still need to emit extern .__floatdidf

The solution for it as :
We record all the lllvm intrinsic extern symbol when transformCallee(), and emit all these symbol in the AsmPrinter::doFinalization(Module &M)

[jasonliu]

llvm/include/llvm/MC/MCContext.h

106

Just a general comment on the data structure that's using here.
Have we thought about using using a SmallPtrSet so that you don't need to worry about inserting the duplicated value into the vector?

423

Is it necessary to have wrappers to the real data structure?
I feel like returning the actual data structure here is not that bad. And user of this data structure have much more freedom using something like range-based for loop, instead of the iterator interface.

llvm/test/CodeGen/PowerPC/aix-llvm-intrinsic.ll

20

nit: remove this Attr.

[DiggerLin]

llvm/include/llvm/MC/MCContext.h

106

/ SmallPtrSet - This class implements a set which is optimized for holding
/ SmallSize or less elements. This internally rounds up SmallSize to the next
/ power of two if it is not already a power of two. See the comments above
/ SmallPtrSetImplBase for details of the algorithm.
template<class PtrType, unsigned SmallSize>
class SmallPtrSet : public SmallPtrSetImpl<PtrType> {

// In small mode SmallPtrSet uses linear search for the elements, so it is
// not a good idea to choose this value too high. You may consider using a
// DenseSet<> instead if you expect many elements in the set.
static_assert(SmallSize <= 32, "SmallSize should be small");

There are hundreds llvm intrinsic function. I will use std::set

[DiggerLin]

address comment

[jasonliu]

llvm/include/llvm/MC/MCContext.h

106

There are hundreds of llvm intrinsic functions. But are you expecting every compilation will contain hundreds of llvm intrinsic functions? I would say most of the time, you would see those less than 8intrinsic functions in one compilation unit , except for some very heavy mathematic case.

[jasonliu]

llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp

1533

Ranged based for loop?

[hubert.reinterpretcast]

llvm/include/llvm/MC/MCContext.h

106

I agree with @jasonliu, and even if SmallPtrSet is too small, why not use DenseSet like the comments say?

[DiggerLin]

address comment

llvm/include/llvm/MC/MCContext.h

106

I think we can not guarantee the llvm intrinsic sysbols in a compilation unit is less than 32. I will use DenseSet.

[DiggerLin]

using SmallPtrSet as comment

[sfertile]

Have you considered not transforming ExternalSymbolSDNodes, but instead supporting them for AIX and then creating the symbol and emitting the linkage for the ExternalSymbol machine operand in the ASMPrinter? The approach this patch takes adds complexity to a target independent part of the MC infrastructure. The amount of complexity it adds is not unreasonable, but I think if we can contain the complexity to the PowerPC backend its worth considering strongly even if the implementation there is more difficult.

[DiggerLin]

upload wrong diff . discard previous diff

[jhenderson]

llvm/include/llvm/MC/MCContext.h

104

Nit: symbol's -> symbols' (or if you don't like that, try "the linkage of these symbols.")

I would write emiting as emitting, but I don't know if that's a British versus American English thing.

Here and in other comments, should "llvm" be "LLVM"?

[DiggerLin]

store llvm intrinsic symbols in the PPCAIXAsmPrinter

[jhenderson]

Please reupload the latest patch with context.

llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp

152 ↗

(On Diff #261728)

Should it be spelt XCOFF?

1756 ↗

(On Diff #261728)

Don't use auto here. Also, should this really be a copy and not a const reference?

llvm/lib/Target/PowerPC/PPCISelLowering.cpp

5284

Should this be const MCSymbolXCOFF *Sym?

llvm/test/CodeGen/PowerPC/aix-llvm-intrinsic.ll

3

Please don't break the lines up like this. I'd put -mattr=altivec on the same line as the rest of the llc line, but if you do want to break it onto a new line, split it roughly halfway through the arguments, and indent the second line, then put the FileCheck line on a new line. Same goes below.

[DiggerLin]

llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp

1756 ↗

(On Diff #261728)

it store the a pointer of MCSymbol in the IntrinsicSymbols. I think return a copy of pointer is same efficient as const reference.

and the

bool MCXCOFFStreamer::emitSymbolAttribute(MCSymbol *Sym,
                                          MCSymbolAttr Attribute)

llvm/lib/Target/PowerPC/PPCISelLowering.cpp

5284

thanks

llvm/test/CodeGen/PowerPC/aix-llvm-intrinsic.ll

3

thanks

[DiggerLin]

address comment

[jasonliu]

llvm/lib/Target/PowerPC/PPCISelLowering.cpp

5264

If there exists a user-declared function whose name is the same as the
ExternalSymbol's, then we pick up the user-declared version.

How do we handle this scenario under the new logic? Are we still able to pick up the user-declared version without generating .extern for that function?

[jasonliu]

llvm/lib/Target/PowerPC/PPCISelLowering.cpp

5264

Please consider the case in llvm/test/CodeGen/PowerPC/aix-user-defined-memcpy.ll

[hubert.reinterpretcast]

llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp

1756 ↗

(On Diff #261728)

One issue with auto here is that it's not obvious that we have a pointer type (and even knowing how Sym is used does not rule out the possibility that it is merely convertible to the pointer type). Using auto * might not have caused the comment to be raised, but since the comment has been raised, please get rid of the auto.

[DiggerLin]

address comment

[jhenderson]

llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp

1756 ↗

(On Diff #261728)

By the way, there's a related style guide section on usage of auto: https://llvm.org/docs/CodingStandards.html#use-auto-type-deduction-to-make-code-more-readable

llvm/test/CodeGen/PowerPC/aix-llvm-intrinsic.ll

3

One more related request: Indent the FileCheck directive by an extra two spaces to make it obvious it's a continuation of the previous line:

; RUN: llc ... | \
; RUN:   FileCheck ...

Same below.

[DiggerLin]

llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp

1756 ↗

(On Diff #261728)

thanks for the information.

[jasonliu]

It's a bit awkward to use the emitInstruction function to record the special functions, as it is actually not doing anything related to "emit instruction".
But I'm not sure if there is any better way to do it if we want to hide the logic in PPCAsmPrinter instead of exposing it in target independent MCContext.
I will see what other people think.

llvm/lib/Target/PowerPC/PPCISelLowering.cpp

5284

Could we have a lambda function to return a MCSymbolXCOFF with the correct name for it? Then replace the similar logic in getAIXFuncEntryPointSymbolSDNode with this lambda function call as well.
We should limit the places to do the "." + func_name dance.

[sfertile]

👍 Thanks for trying this out Digger, I think this approach is the right one to take. I've had an initial look and left a few comments inline. I'll need to spend some time understanding ExternalSymbolSDNodes a bit better before being able to review the patch thoroughly enough to approve.

llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp

152 ↗

(On Diff #261728)

IIUC this isn't directly related to intrinsics, but to ExternalSymbolSD nodes, with the lowering of intrinsics being just one of the ways we can end up with an ExternalSymbolSDNodes. Intrinsic lowering might be the only way we expect to get one of these nodes on AIX right now but that can change in the future. The naming and comments need to reflect that this is explicitly for handling emitting the linkage of ExternalSymbolSDNodes.

1726 ↗

(On Diff #262155)

Choosing to implement this override and handle here instead of adding to the base classes emitInstruction makes this really nice and clean. Good job.

1733 ↗

(On Diff #262155)

What is the state of tail-calls on AIX? I know we can't tail call in many of the situations where we can on Linux, however if they aren't completely disabled we might need to add the tail-call opcodes here for similar transformation.

llvm/lib/Target/PowerPC/PPCISelLowering.cpp

5272

I'm not too familiar with when we get ExternalSymbolSDNodes or what the semantic should be if we have an ExternalSymbolSDNode and a IR declaration for the same function, but it seems odd to treat the situation differently based on XCOFF vs ELF. @Xiangling_L Was aix-user-defined-memcpy.ll motivated by real code? If so I'd like to investigate it a bit more.

5283

Why not leave the name as is, and prepend the '.' when we create/lookup the symbol in the AsmPrinter?

[jasonliu]

llvm/lib/Target/PowerPC/PPCISelLowering.cpp

5272

It seems for real C code. If there is a user-provided memset/memcpy, clang would transform the call to that user-provided memset/memcpy instead of generating llvm.memset/memcpy intrinsic.

[DiggerLin]

llvm/lib/Target/PowerPC/PPCISelLowering.cpp

5283

if leave name as is, the branch will be
bl memset
not
bl .memset

if leave name as is , we want to generate bl .memset . we need to modify the operand(ExternalSymbol) of branch to generate correct bl .memset

[DiggerLin]

address comment

[sfertile]

llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp

152 ↗

(On Diff #261728)

Sorry I wasn't more explicit in my previous comment. I don't think we should be using the name 'intrinsic' here at all.

/// Symbols lowered from ExternalSymbolSDNodes.
SmallPtrSet<MCSymbol *, 8> ExternalSymbols;

1734 ↗

(On Diff #262677)

We haven't implemented TLS on AIX yet, and I'm not sure which if any of these call pseudos will be used. How about adding them as a separate case with a report_fatal_error which can be revisited as part of TLS implementation on AIX.

llvm/lib/Target/PowerPC/PPCISelLowering.cpp

5241

I'm don't think this is what Jason meant from his comment.

5283

Yes, which is why I said you would move where you prepend the '.' from here, to where you create the MCSymbol from the MO_ExternalSymbol in the ASM printer.

I think our handling of when there is deceleration in the IR matching the ExtrernalSymbol name is wrong, and it should either be done for all subtargets, or none (but I'm not 100% sure of that yet and investigating). If they are to be common-ed, then by moving modifying the symbols name too the ASMprinter, it lets us have identical code for all subtargets for transforming ExternalSymbolSDNode callees.

I'd say hold off on making this change until we better understand the IR Decl/ExternalSym situation though.

[DiggerLin]

llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp

152 ↗

(On Diff #261728)

thanks

1734 ↗

(On Diff #262677)

I will delete the TLS related opcode.

llvm/lib/Target/PowerPC/PPCISelLowering.cpp

5241

thanks.

5283

Discussed with Sean offline, I will keep the implement.

[DiggerLin]

address comment

[sfertile]

llvm/lib/Target/PowerPC/PPCISelLowering.cpp

5283

Expanding a bit: I though we could create the MCSymbol in PPCAIXAsmPrinter::emitInstruction and then create a new MCSymbol MachineOperand and change the operand to that. Digger explained how I was mistaken and we can not change the operand on the MachineInstr, so we have to stick with this approach.

[sfertile]

llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp

153 ↗

(On Diff #263179)

Not all intrinsics get handled this way, and not all of these symbols necessarily come from lowering an intrinsic: so we shouldn't be using 'Intrinsic' in the naming. I suggested 'ExternalSymbols' above but that sprobably too generic.

1733 ↗

(On Diff #262155)

You have added PPC::TAILB so I am assuming that means we do support tail-calls on AIX. Why do we not need to add any of the other tail call pseudos. At the very least i would expect we need PPC::TAILB8 for 64-bit support if we expect TAILB for 32-bit. What about TAILBA[8] or TAILBCTR[8]?

[Xiangling_L]

Can you also please update the testcase aix-user-defined-memcpy.ll to include:
CHECK-NOT: .extern .memcpy

llvm/lib/Target/PowerPC/PPCISelLowering.cpp

5272

Just as a record. As we discussed offline, a real C code is like:

int memcpy ( void * destination, int num ) { return 3; }
typedef struct cpy_array {
  int array[20];
} cpy;
int main() {
  cpy A = {1,2,3,4,5,6,7,8,9,10, 11, 12, 13, 14, 15,16};
  cpy B = A;
  return B.array[0];
}

And Clang FE will generate the following IR for AIX:

; Function Attrs: noinline nounwind optnone
define i32 @memcpy(i8* %destination, i32 %num) #0 {
entry:
  %destination.addr = alloca i8*, align 4
  %num.addr = alloca i32, align 4
  store i8* %destination, i8** %destination.addr, align 4
  store i32 %num, i32* %num.addr, align 4
  ret i32 3
}
; Function Attrs: noinline nounwind optnone
define i32 @main() #0 {
entry:
  %retval = alloca i32, align 4
  %A = alloca %struct.cpy_array, align 4
  %B = alloca %struct.cpy_array, align 4
  store i32 0, i32* %retval, align 4
  %0 = bitcast %struct.cpy_array* %A to i8*
  call void @llvm.memcpy.p0i8.p0i8.i32(i8* align 4 %0, i8* align 4 bitcast (%struct.cpy_array* @__const.main.A to i8*), i32 80, i1 false)
  %1 = bitcast %struct.cpy_array* %B to i8*
  %2 = bitcast %struct.cpy_array* %A to i8*
  call void @llvm.memcpy.p0i8.p0i8.i32(i8* align 4 %1, i8* align 4 %2, i32 80, i1 false)
  %array = getelementptr inbounds %struct.cpy_array, %struct.cpy_array* %B, i32 0, i32 0
  %arrayidx = getelementptr inbounds [20 x i32], [20 x i32]* %array, i32 0, i32 0
  %3 = load i32, i32* %arrayidx, align 4
  ret i32 %3
}

llvm/test/CodeGen/PowerPC/aix-cc-byval-mem.ll

91 ↗

(On Diff #263179)

Though unrelated to this patch, I am wondering if we can replace & to something more meaningful like extsym etc. like what we have for MCSymbol as mcsymbol?

[sfertile]

llvm/test/CodeGen/PowerPC/aix-cc-byval-mem.ll

91 ↗

(On Diff #263179)

Good suggestion, send a quick email to the llvm-dev list and see if there interest for this, or any objections.

[DiggerLin]

llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp

153 ↗

(On Diff #263179)

thanks . change to "ExtSymSDNodeSymbols" as you discussed on the slack

1733 ↗

(On Diff #262155)

as discussed with Sean offline, since wo do not support tail call for the extern symbol now . I added a report_fatal_error("Tail call for extern symbol not yet implemented.");

[DiggerLin]

address comment

[jhenderson]

llvm/test/CodeGen/PowerPC/aix-user-defined-memcpy.ll

11–12 ↗

(On Diff #266075)

I know this is what was done elsewhere in the test, but I don't think we should blindly copy bad practice here, and instead you should just reflow the line like I suggested in the other test. If you do think the llc line is too long and needs to broken up, I'd recommend the following:

; RUN: llc -verify-machineinstrs -mtriple powerpc-ibm-aix-xcoff \
; RUN:     -mcpu=pwr4 -mattr=-altivec < %s | \
; RUN:   FileCheck %s

[jhenderson]

No more style/test comments from me now. I don't know enough about other things to further review this.

[hubert.reinterpretcast]

llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp

1734 ↗

(On Diff #262677)

Can we have an update on why the TLS call pseudos were simply removed instead of being tracked by report_fatal_error as @sfertile suggested? I think that leaving some breadcrumbs in the code would be useful.

1763 ↗

(On Diff #266563)

Please use the immediate base class name to refer to the base class implementation.

[hubert.reinterpretcast]

llvm/lib/Target/PowerPC/PPCISelLowering.cpp

5221

Should the name be adjusted to match that of the function introduced by https://reviews.llvm.org/D80402? @jasonliu?

llvm/test/CodeGen/PowerPC/aix-cc-byval-mem.ll

91 ↗

(On Diff #263179)

@sfertile, do we have further news on this?

llvm/test/CodeGen/PowerPC/aix-llvm-intrinsic.ll

9

We've been indenting options to line up with options on the previous line. That usually avoids indenting by only two spaces (which we may want to reserve for indentation after things like shell operators).

13

Same comment.

[jasonliu]

llvm/lib/Target/PowerPC/PPCISelLowering.cpp

5221

Yeah, I think matching them would be useful for grepping.

[hubert.reinterpretcast]

llvm/test/CodeGen/PowerPC/aix-llvm-intrinsic.ll

43

Start with COMMON-LABEL with this line and omit the lines above. The existence of the function descriptor is not the purpose of this test. After this, there would be no difference between 32-bit and 64-bit and we should be able to replace the prefix with plain CHECK.

46

I think the object code generation path test needs to verify that the relocation refers to the correct symbol table entry.

52

I think we should similarly omit the lines in this block before this last one.

75

I think we can omit the symbol table entries aside from the one for .memset.

[DiggerLin]

address comment

llvm/lib/Target/PowerPC/PPCISelLowering.cpp

5221

I do not think we can use MCSymbol *getFunctionEntryPointSymbol(const Function *F,const TargetMachine &TM) function , for the .memset or memcpy, we do not have Function object for it.

[jasonliu]

llvm/lib/Target/PowerPC/PPCISelLowering.cpp

5221

I don't think you can actually call that function, as the function is in TLOF and you do not have access to that from here.
Hubert and I are talking about matching the name.

[jhenderson]

llvm/test/CodeGen/PowerPC/aix-llvm-intrinsic.ll

10–12

You can fold these two lines into one. No need for them to be separate:

; RUN: llvm-readobj --symbols --relocations --expand-relocs %t.o | \
; RUN:   FileCheck --check-prefix=SYMRELOC %s

[DiggerLin]

address comment

llvm/test/CodeGen/PowerPC/aix-llvm-intrinsic.ll

10–12

Thanks for your suggestion, but I think separating in two is based is more reasonable ,One test for test Symbol. other test for test relocation. it is more readable.

[jhenderson]

llvm/test/CodeGen/PowerPC/aix-llvm-intrinsic.ll

10–12

I'm not sure how it's more readable. It's very clear from my suggested command-line that we want to test the symbols and relocations (otherwise the options wouldn't be present), and would reduce the amount of work required to figure out which checks below correspond to which FileCheck line.

It would also be more in keeping with most tests I've worked with, and would reduce the number of executable invocations from 4 to 2, improving test run time.

[DiggerLin]

llvm/test/CodeGen/PowerPC/aix-llvm-intrinsic.ll

10–12

I tried it with llvm-readobj --symbols --relocations --expand-relocs
it display the relocation information first and than symbol information.

in the test case we want to verify symbol first and than relocation.
I have to keep current test.

[DiggerLin]

llvm/test/CodeGen/PowerPC/aix-llvm-intrinsic.ll

10–12

@hubert.reinterpretcast , what is your option on combine the

llvm-readobj --symbols

and

llvm-readobj --relocations --expand-relocs

into

llvm-readobj --symbols --relocations --expand-relocs

and than verify relocation information first as

; SYMRELOC: Relocation {{[{][[:space:]] *}}Virtual Address: 0x18
; SYMRELOC-NEXT: Symbol: .memset (0)
; SYMRELOC-NEXT: IsSigned: Yes
; SYMRELOC-NEXT: FixupBitValue: 0
; SYMRELOC-NEXT: Length: 26
; SYMRELOC-NEXT: Type: R_RBR (0x1A)
; SYMRELOC-NEXT: }

; SYMRELOC: Symbol {
; SYMRELOC-NEXT: Index: 0
; SYMRELOC-NEXT: Name: .memset
; SYMRELOC-NEXT: Value (RelocatableAddress): 0x0
; SYMRELOC-NEXT: Section: N_UNDEF
; SYMRELOC-NEXT: Type: 0x0
; SYMRELOC-NEXT: StorageCl
......

[hubert.reinterpretcast]

llvm/test/CodeGen/PowerPC/aix-llvm-intrinsic.ll

10–12

I suggest using llvm-objdump -d --symbol-description for the relocation check. As it is, we can't tell whether the relocation we found is in the right place. This happens to make it so that we end up with two separate tool invocations.

33

I believe I requested CHECK-LABEL: here.

35

Please indent the instructions in relation to the label.

61

Moot point, but this should be aligned to match the closing brace.

[jasonliu]

llvm/test/CodeGen/PowerPC/aix-llvm-intrinsic.ll

10–12

I think you meant: llvm-objdump -d -r --symbol-description

[jhenderson]

llvm/test/CodeGen/PowerPC/aix-llvm-intrinsic.ll

10–12

It's moot, given the llvm-objdump suggestion, but I'm not sure it really matters which order symbols or relocations are printed in.

[DiggerLin]

llvm/test/CodeGen/PowerPC/aix-llvm-intrinsic.ll

10–12

because there is symbol index in the relocation information. we prefer to verify the symbol first and then relocation. otherwise, when we verified relocation, we have to go down the test file to search the symbol information.

[DiggerLin]

change test case based on comment

[sfertile]

Hey Digger, sorry for letting this sit for so long. Feel free to ping reviews periodically to get peoples attention back on them.

Other then a few minor nits, LGTM.

llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp

152 ↗

(On Diff #268466)

Minor nit: Mention that we will need the emit extern linkage for them in the comment.

1800 ↗

(On Diff #268466)

nit: I would instead say 'not supported' or 'not expected'. The AIX ABI makes a tail-call to an external symbol really unexpected.

llvm/test/CodeGen/PowerPC/aix-cc-byval-mem.ll

91 ↗

(On Diff #263179)

Not sure, I suggested @Xiangling_L send an email to the dev list to discuss, but never followed whether it happened or not. Either way I think its outside the scope of this patch.

[Xiangling_L]

llvm/test/CodeGen/PowerPC/aix-cc-byval-mem.ll

91 ↗

(On Diff #263179)

Sorry, I think there were some miscommunications. I thought you would send the email. Thanks for your suggestion and will do.

llvm/include/llvm/MC/MCContext.h

 //===- MCContext.h - Machine Code Context -----------------------*- C++ -*-===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 
 #ifndef LLVM_MC_MCCONTEXT_H
 #define LLVM_MC_MCCONTEXT_H
 
 #include "llvm/ADT/DenseMap.h"
 #include "llvm/ADT/Optional.h"
 #include "llvm/ADT/SetVector.h"
+#include "llvm/ADT/SmallPtrSet.h"
 #include "llvm/ADT/SmallString.h"
 #include "llvm/ADT/SmallVector.h"
 #include "llvm/ADT/StringMap.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/ADT/Twine.h"
 #include "llvm/BinaryFormat/Dwarf.h"
 #include "llvm/BinaryFormat/ELF.h"
 #include "llvm/BinaryFormat/XCOFF.h"
private:
     SpecificBumpPtrAllocator<MCSectionELF> ELFAllocator;
     SpecificBumpPtrAllocator<MCSectionMachO> MachOAllocator;
     SpecificBumpPtrAllocator<MCSectionWasm> WasmAllocator;
     SpecificBumpPtrAllocator<MCSectionXCOFF> XCOFFAllocator;
 
     /// Bindings of names to symbols.
     SymbolTable Symbols;
 
+    /// llvm extern intrinsic xcoff symbols used for emiting these symbol's
+    /// linkage.
+    SmallPtrSet<MCSymbol *, 8> XCOFFIntrinsicSymbols;
+
     /// A mapping from a local label number and an instance count to a symbol.
     /// For example, in the assembly
     ///     1:
     ///     2:
     ///     1:
     /// We have three labels represented by the pairs (1, 0), (2, 0) and (1, 1)
     DenseMap<std::pair<unsigned, unsigned>, MCSymbol *> LocalSymbols;
 
public:
 
     MCSymbol *getOrCreateParentFrameOffsetSymbol(StringRef FuncName);
 
     MCSymbol *getOrCreateLSDASymbol(StringRef FuncName);
 
     /// Get the symbol for \p Name, or null.
     MCSymbol *lookupSymbol(const Twine &Name) const;
 
+    /// Get XCOFF Intrinsic entern symbols DenseSet.
+    SmallPtrSet<MCSymbol *, 8> &getXCOFFIntrinsicExternSymbol() {
+      return XCOFFIntrinsicSymbols;
+    }
+
     /// Set value for a symbol.
     void setSymbolValue(MCStreamer &Streamer, StringRef Sym, uint64_t Val);
 
     /// getSymbols - Get a reference for the symbol table for clients that
     /// want to, for example, iterate over all symbols. 'const' because we
     /// still want any modifications to the table itself to use the MCContext
     /// APIs.
     const SymbolTable &getSymbols() const { return Symbols; }

llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp

for (const Function &F : M) {
 
     GlobalValue::VisibilityTypes V = F.getVisibility();
     if (V == GlobalValue::DefaultVisibility)
       continue;
 
     emitVisibility(Name, V, false);
   }
 
+  // Emit linkage for llvm intrinsic function entry point symbol.
+  if (TM.getTargetTriple().isOSBinFormatXCOFF()) {
+    for (auto Sym : OutContext.getXCOFFIntrinsicExternSymbol()) {
+      OutStreamer->emitSymbolAttribute(Sym, MCSA_Extern);
+    }
+  }
   // Emit the remarks section contents.
   // FIXME: Figure out when is the safest time to emit this section. It should
   // not come after debug info.
   if (remarks::RemarkStreamer *RS = M.getContext().getMainRemarkStreamer())
     emitRemarksSection(*RS);
 
   const TargetLoweringObjectFile &TLOF = getObjFileLowering();
 

llvm/lib/Target/PowerPC/PPCISelLowering.cpp

bool UsePlt =
       Subtarget.getTargetMachine().getRelocationModel() == Reloc::PIC_;
 
   // On AIX, direct function calls reference the symbol for the function's
   // entry point, which is named by prepending a "." before the function's
   // C-linkage name.
   const auto getAIXFuncEntryPointSymbolSDNode =
       [&](StringRef FuncName, bool IsDeclaration,
           const XCOFF::StorageClass &SC) {
         auto &Context = DAG.getMachineFunction().getMMI().getContext();
 
         MCSymbolXCOFF *S = cast<MCSymbolXCOFF>(
             Context.getOrCreateSymbol(Twine(".") + Twine(FuncName)));
 
         if (IsDeclaration && !S->hasRepresentedCsectSet()) {
           // On AIX, an undefined symbol needs to be associated with a
           // MCSectionXCOFF to get the correct storage mapping class.
           // In this case, XCOFF::XMC_PR.
           MCSectionXCOFF *Sec = Context.getXCOFFSection(
               S->getName(), XCOFF::XMC_PR, XCOFF::XTY_ER, SC,
               SectionKind::getMetadata());
           S->setRepresentedCsect(Sec);
         }
 
         MVT PtrVT =
             DAG.getTargetLoweringInfo().getPointerTy(DAG.getDataLayout());
         return DAG.getMCSymbol(S, PtrVT);
       };
 
   if (isFunctionGlobalAddress(Callee)) {
     const GlobalAddressSDNode *G = cast<GlobalAddressSDNode>(Callee);
     const GlobalValue *GV = G->getGlobal();
 
     if (!Subtarget.isAIXABI())
       return DAG.getTargetGlobalAddress(GV, dl, Callee.getValueType(), 0,
                                         UsePlt ? PPCII::MO_PLT : 0);
 
     assert(!isa<GlobalIFunc>(GV) && "IFunc is not supported on AIX.");
     const GlobalObject *GO = cast<GlobalObject>(GV);
     const XCOFF::StorageClass SC =
         TargetLoweringObjectFileXCOFF::getStorageClassForGlobal(GO);
     return getAIXFuncEntryPointSymbolSDNode(GO->getName(), GO->isDeclaration(),
                                             SC);
   }
 
   if (ExternalSymbolSDNode *S = dyn_cast<ExternalSymbolSDNode>(Callee)) {
     const char *SymName = S->getSymbol();
     if (!Subtarget.isAIXABI())
       return DAG.getTargetExternalSymbol(SymName, Callee.getValueType(),
                                          UsePlt ? PPCII::MO_PLT : 0);
 
     // If there exists a user-declared function whose name is the same as the
     // ExternalSymbol's, then we pick up the user-declared version.
     const Module *Mod = DAG.getMachineFunction().getFunction().getParent();
     if (const Function *F =
             dyn_cast_or_null<Function>(Mod->getNamedValue(SymName))) {
       const XCOFF::StorageClass SC =
           TargetLoweringObjectFileXCOFF::getStorageClassForGlobal(F);
       return getAIXFuncEntryPointSymbolSDNode(F->getName(), F->isDeclaration(),
                                               SC);
     }
-
+    auto &Context = DAG.getMachineFunction().getMMI().getContext();
+    MCSymbolXCOFF *Sym = cast<MCSymbolXCOFF>(
+        Context.getOrCreateSymbol(Twine(".") + Twine(SymName)));
+    Context.getXCOFFIntrinsicExternSymbol().insert(Sym);
     return getAIXFuncEntryPointSymbolSDNode(SymName, true, XCOFF::C_EXT);
   }
 
   // No transformation needed.
   assert(Callee.getNode() && "What no callee?");
   return Callee;
 }
 
 static SDValue getOutputChainFromCallSeq(SDValue CallSeqStart) {
   assert(CallSeqStart.getOpcode() == ISD::CALLSEQ_START &&
          "Expected a CALLSEQ_STARTSDNode.");
 
   // The last operand is the chain, except when the node has glue. If the node
   // has glue, then the last operand is the glue, and the chain is the second
   // last operand.
   SDValue LastValue = CallSeqStart.getValue(CallSeqStart->getNumValues() - 1);

llvm/test/CodeGen/PowerPC/aix-llvm-intrinsic.ll

+; RUN: llc -verify-machineinstrs -mtriple powerpc-ibm-aix-xcoff -mcpu=pwr4 \
+; RUN: -mattr=-altivec < %s | FileCheck --check-prefixes=COMMON,BIT32 %s
+
+; RUN: llc -verify-machineinstrs -mtriple powerpc64-ibm-aix-xcoff -mcpu=pwr4 \
+; RUN: -mattr=-altivec < %s | FileCheck --check-prefixes=COMMON,BIT64 %s
+
+; RUN: llc -verify-machineinstrs -mtriple powerpc-ibm-aix-xcoff -mcpu=pwr4 \
+; RUN: -mattr=-altivec -filetype=obj -o %t.o < %s
+; RUN: llvm-readobj --symbols %t.o | FileCheck --check-prefix=CHECKSYM %s
+
+; RUN: not --crash llc -verify-machineinstrs -mcpu=pwr4 -mtriple powerpc64-ibm-aix-xcoff \
+; RUN: -mattr=-altivec -filetype=obj -o %t.o 2>&1 < %s | FileCheck --check-prefix=XCOFF64 %s
+; XCOFF64: LLVM ERROR: 64-bit XCOFF object files are not supported yet.
+
+%struct.S = type { i32, i32 }
+
+@s = external global %struct.S, align 4
+
+define void @bar() {
+entry:
+  %0 = load i32, i32* getelementptr inbounds (%struct.S, %struct.S* @s, i32 0, i32 1), align 4
+  %1 = trunc i32 %0 to i8
+  %2 = load i32, i32* getelementptr inbounds (%struct.S, %struct.S* @s, i32 0, i32 1), align 4
+  call void @llvm.memset.p0i8.i32(i8* align 4 bitcast (%struct.S* @s to i8*), i8 %1, i32 %2, i1 false)
+  ret void
+}
+
+declare void @llvm.memset.p0i8.i32(i8* nocapture writeonly, i8, i32, i1 immarg)
+
+; COMMON:       .globl  bar[DS]                 # -- Begin function bar
+; COMMON-NEXT:  .globl  .bar
+; COMMON-NEXT:  .align  4
+; COMMON-NEXT:  .csect bar[DS]
+; BIT32-NEXT:   .long   .bar                    # @bar
+; BIT64-NEXT:   .llong  .bar                    # @bar
+; BIT32-NEXT:   .long   TOC[TC0]
+; BIT64-NEXT:   .llong  TOC[TC0]
+; BIT32-NEXT:   .long  0
+; BIT64-NEXT:   .llong  0
+; COMMON-NEXT:  .csect .text[PR]
+; COMMON-NEXT: .bar:
+; COMMON-NEXT: # %bb.0:                                # %entry
+; COMMON-NEXT:  mflr 0
+; COMMON:       bl .memset
+
+; COMMON:       .extern s[UA]
+; COMMON-NEXT:  .extern .memset
+; COMMON-NEXT:  .toc
+; COMMON-NEXT: LC0:
+; COMMON-NEXT:  .tc s[TC],s[UA]
+
+; CHECKSYM:      Symbols [
+; CHECKSYM-NEXT:   Symbol {
+; CHECKSYM-NEXT:     Index: [[#Index:]]
+; CHECKSYM-NEXT:     Name: .memset
+; CHECKSYM-NEXT:     Value (RelocatableAddress): 0x0
+; CHECKSYM-NEXT:     Section: N_UNDEF
+; CHECKSYM-NEXT:     Type: 0x0
+; CHECKSYM-NEXT:     StorageClass: C_EXT (0x2)
+; CHECKSYM-NEXT:     NumberOfAuxEntries: 1
+; CHECKSYM-NEXT:     CSECT Auxiliary Entry {
+; CHECKSYM-NEXT:       Index: [[#Index+1]]
+; CHECKSYM-NEXT:       SectionLen: 0
+; CHECKSYM-NEXT:       ParameterHashIndex: 0x0
+; CHECKSYM-NEXT:       TypeChkSectNum: 0x0
+; CHECKSYM-NEXT:       SymbolAlignmentLog2: 0
+; CHECKSYM-NEXT:       SymbolType: XTY_ER (0x0)
+; CHECKSYM-NEXT:       StorageMappingClass: XMC_PR (0x0)
+; CHECKSYM-NEXT:       StabInfoIndex: 0x0
+; CHECKSYM-NEXT:       StabSectNum: 0x0
+; CHECKSYM-NEXT:     }
+; CHECKSYM-NEXT:   }
+; CHECKSYM-NEXT:   Symbol {
+; CHECKSYM-NEXT:     Index: [[#Index+2]]
+; CHECKSYM-NEXT:     Name: s
+; CHECKSYM-NEXT:     Value (RelocatableAddress): 0x0
+; CHECKSYM-NEXT:     Section: N_UNDEF
+; CHECKSYM-NEXT:     Type: 0x0
+; CHECKSYM-NEXT:     StorageClass: C_EXT (0x2)
+; CHECKSYM-NEXT:     NumberOfAuxEntries: 1
+; CHECKSYM-NEXT:     CSECT Auxiliary Entry {
+; CHECKSYM-NEXT:       Index: [[#Index+3]]
+; CHECKSYM-NEXT:       SectionLen: 0
+; CHECKSYM-NEXT:       ParameterHashIndex: 0x0
+; CHECKSYM-NEXT:       TypeChkSectNum: 0x0
+; CHECKSYM-NEXT:       SymbolAlignmentLog2: 0
+; CHECKSYM-NEXT:       SymbolType: XTY_ER (0x0)
+; CHECKSYM-NEXT:       StorageMappingClass: XMC_UA (0x4)
+; CHECKSYM-NEXT:       StabInfoIndex: 0x0
+; CHECKSYM-NEXT:       StabSectNum: 0x0
+; CHECKSYM-NEXT:     }
+; CHECKSYM-NEXT:   }
+; CHECKSYM-NEXT:   Symbol {
+; CHECKSYM-NEXT:     Index: [[#Index+4]]
+; CHECKSYM-NEXT:     Name: .text
+; CHECKSYM-NEXT:     Value (RelocatableAddress): 0x0
+; CHECKSYM-NEXT:     Section: .text
+; CHECKSYM-NEXT:     Type: 0x0
+; CHECKSYM-NEXT:     StorageClass: C_HIDEXT (0x6B)
+; CHECKSYM-NEXT:     NumberOfAuxEntries: 1
+; CHECKSYM-NEXT:     CSECT Auxiliary Entry {
+; CHECKSYM-NEXT:       Index: [[#Index+5]]
+; CHECKSYM-NEXT:       SectionLen: 48
+; CHECKSYM-NEXT:       ParameterHashIndex: 0x0
+; CHECKSYM-NEXT:       TypeChkSectNum: 0x0
+; CHECKSYM-NEXT:       SymbolAlignmentLog2: 4
+; CHECKSYM-NEXT:       SymbolType: XTY_SD (0x1)
+; CHECKSYM-NEXT:       StorageMappingClass: XMC_PR (0x0)
+; CHECKSYM-NEXT:       StabInfoIndex: 0x0
+; CHECKSYM-NEXT:       StabSectNum: 0x0
+; CHECKSYM-NEXT:     }
+; CHECKSYM-NEXT:   }
+; CHECKSYM-NEXT:   Symbol {
+; CHECKSYM-NEXT:     Index: [[#Index+6]]
+; CHECKSYM-NEXT:     Name: .bar
+; CHECKSYM-NEXT:     Value (RelocatableAddress): 0x0
+; CHECKSYM-NEXT:     Section: .text
+; CHECKSYM-NEXT:     Type: 0x0
+; CHECKSYM-NEXT:     StorageClass: C_EXT (0x2)
+; CHECKSYM-NEXT:     NumberOfAuxEntries: 1
+; CHECKSYM-NEXT:     CSECT Auxiliary Entry {
+; CHECKSYM-NEXT:       Index: [[#Index+7]]
+; CHECKSYM-NEXT:       ContainingCsectSymbolIndex: [[#Index+4]]
+; CHECKSYM-NEXT:       ParameterHashIndex: 0x0
+; CHECKSYM-NEXT:       TypeChkSectNum: 0x0
+; CHECKSYM-NEXT:       SymbolAlignmentLog2: 0
+; CHECKSYM-NEXT:       SymbolType: XTY_LD (0x2)
+; CHECKSYM-NEXT:       StorageMappingClass: XMC_PR (0x0)
+; CHECKSYM-NEXT:       StabInfoIndex: 0x0
+; CHECKSYM-NEXT:       StabSectNum: 0x0
+; CHECKSYM-NEXT:     }
+; CHECKSYM-NEXT:   }
+; CHECKSYM-NEXT:   Symbol {
+; CHECKSYM-NEXT:     Index: [[#Index+8]]
+; CHECKSYM-NEXT:     Name: bar
+; CHECKSYM-NEXT:     Value (RelocatableAddress): 0x30
+; CHECKSYM-NEXT:     Section: .data
+; CHECKSYM-NEXT:     Type: 0x0
+; CHECKSYM-NEXT:     StorageClass: C_EXT (0x2)
+; CHECKSYM-NEXT:     NumberOfAuxEntries: 1
+; CHECKSYM-NEXT:     CSECT Auxiliary Entry {
+; CHECKSYM-NEXT:       Index: [[#Index+9]]
+; CHECKSYM-NEXT:       SectionLen: 12
+; CHECKSYM-NEXT:       ParameterHashIndex: 0x0
+; CHECKSYM-NEXT:       TypeChkSectNum: 0x0
+; CHECKSYM-NEXT:       SymbolAlignmentLog2: 2
+; CHECKSYM-NEXT:       SymbolType: XTY_SD (0x1)
+; CHECKSYM-NEXT:       StorageMappingClass: XMC_DS (0xA)
+; CHECKSYM-NEXT:       StabInfoIndex: 0x0
+; CHECKSYM-NEXT:       StabSectNum: 0x0
+; CHECKSYM-NEXT:     }
+; CHECKSYM-NEXT:   }
+; CHECKSYM-NEXT:   Symbol {
+; CHECKSYM-NEXT:     Index: [[#Index+10]]
+; CHECKSYM-NEXT:     Name: TOC
+; CHECKSYM-NEXT:     Value (RelocatableAddress): 0x3C
+; CHECKSYM-NEXT:     Section: .data
+; CHECKSYM-NEXT:     Type: 0x0
+; CHECKSYM-NEXT:     StorageClass: C_HIDEXT (0x6B)
+; CHECKSYM-NEXT:     NumberOfAuxEntries: 1
+; CHECKSYM-NEXT:     CSECT Auxiliary Entry {
+; CHECKSYM-NEXT:       Index: [[#Index+11]]
+; CHECKSYM-NEXT:       SectionLen: 0
+; CHECKSYM-NEXT:       ParameterHashIndex: 0x0
+; CHECKSYM-NEXT:       TypeChkSectNum: 0x0
+; CHECKSYM-NEXT:       SymbolAlignmentLog2: 2
+; CHECKSYM-NEXT:       SymbolType: XTY_SD (0x1)
+; CHECKSYM-NEXT:       StorageMappingClass: XMC_TC0 (0xF)
+; CHECKSYM-NEXT:       StabInfoIndex: 0x0
+; CHECKSYM-NEXT:       StabSectNum: 0x0
+; CHECKSYM-NEXT:     }
+; CHECKSYM-NEXT:   }
+; CHECKSYM-NEXT:   Symbol {
+; CHECKSYM-NEXT:     Index: [[#Index+12]]
+; CHECKSYM-NEXT:     Name: s
+; CHECKSYM-NEXT:     Value (RelocatableAddress): 0x3C
+; CHECKSYM-NEXT:     Section: .data
+; CHECKSYM-NEXT:     Type: 0x0
+; CHECKSYM-NEXT:     StorageClass: C_HIDEXT (0x6B)
+; CHECKSYM-NEXT:     NumberOfAuxEntries: 1
+; CHECKSYM-NEXT:     CSECT Auxiliary Entry {
+; CHECKSYM-NEXT:       Index: [[#Index+13]]
+; CHECKSYM-NEXT:       SectionLen: 4
+; CHECKSYM-NEXT:       ParameterHashIndex: 0x0
+; CHECKSYM-NEXT:       TypeChkSectNum: 0x0
+; CHECKSYM-NEXT:       SymbolAlignmentLog2: 2
+; CHECKSYM-NEXT:       SymbolType: XTY_SD (0x1)
+; CHECKSYM-NEXT:       StorageMappingClass: XMC_TC (0x3)
+; CHECKSYM-NEXT:       StabInfoIndex: 0x0
+; CHECKSYM-NEXT:       StabSectNum: 0x0
+; CHECKSYM-NEXT:     }
+; CHECKSYM-NEXT:   }
+; CHECKSYM-NEXT: ]
+