[PowerPC] Only use PLT annotations if using PIC relocation model

[jhibbits]

Summary

The default static (non-PIC, non-PIE) model for 32-bit powerpc does not
use @PLT annotations and relocations in GCC. LLVM shouldn't use @PLT
annotations either, because it breaks secure-PLT linking with GNU LD.

Update the available-externally.ll test to reflect that default mode should be
the same as the static relocation, by using the same check prefix.

[Bdragon28]

This doesn't seem quite sufficient for FreeBSD kernel modules. It's emitting R_PPC_REL24 instead of R_PPC_ADDR16_HA/R_PPC_ADDR16_LO pairs for stuff like memset and memcpy, which are unusable because we're running modules in KVA and the kernel text in the 32 bit DMAP. Still need to figure out why these are being emitted this way when using freestanding.

[vit9696]

This change makes good sense to me, as I suggested pretty much the same thing 2 years ago (D38554). In the end for us it was easier to fix LLD and switch to GNU ABI ignoring IFUNC support entirely than to convince the others and support the change. Yet either way believe that it is logical not to emit PLT for static memory model. Personally I can accept this, but I wonder whether there are more comments coming.

[Bdragon28]

On the FreeBSD kernel side, I put some time into working out the missing parts on ppc32 and slightly extending the kernel linker to support secure-plt PIC kernel modules. Working on that over at https://reviews.freebsd.org/D22608.

[sfertile]

Hi Justin,

I'd like to help reviewing this patch. I know how calls work in the 2 64-bit ELF abis pretty well but am not familiar with 32-bit PowerPC at all so I have a handful of questions to start:

1. I've been using this ABI DOC. Is this the 32-bit ABI supported in LLVM? Are there other 32-bit ELF PowerPC Abis I need to be aware of?
2. What secure-plt reference or references should I read to get up to speed?

Finally I'd like to just verify my base understanding of the difference between bl sym and bl sym@PLT.

bl sym will produce a call instruction with an R_PPC_REL24 relocation, which will tell the linker to fill in the instruction with the offset from the program counter at the call instruction to sym.
bl sym@PLT will produce a call instruction with an R_PPC_PLTREL24 which will instruct the linker to create a PLT, allocate a PLT entry for sym, and fill in the instruction with the offset from the program counter to the PLT entry for 'sym'.

I'm used to having 1 relocation type for both calls, and the linker can determine based on the properties of 'sym' and whether its linking a shared object or not whether the call needs to indirect through the PLT.

• If you emit a call instruction with the PLTREL relocation but the symbol ends up module local, does the linker convert the call to a local one?
• Is it an error to not use a PLTREL relocation for a call that needs to be indirected through the PLT or is the linker smart enough to add a PLT entry for the symbol and branch to there instead?

[sfertile]

In D70570#1758956, @Bdragon28 wrote:

This doesn't seem quite sufficient for FreeBSD kernel modules. It's emitting R_PPC_REL24 instead of R_PPC_ADDR16_HA/R_PPC_ADDR16_LO pairs for stuff like memset and memcpy,
which are unusable because we're running modules in KVA and the kernel text in the 32 bit DMAP. Still need to figure out why these are being emitted this way when using freestanding.

With those relocations, are you building up the address of memset/memcpy directly and performing an indirect call?
eg, something along the lines of:

addis r12, r0, memset@ha
addi r12, r12, memset@l
mtctr r12
bctrl

[jhibbits]

@Bdragon28 we might need to use -mlongcall for modules, if we aren't already. This should(?) force the compiler to generate the appropriate long-distance code sequences. I'm not sure, though, if clang supports this yet.

@sfertile Thanks for reviewing this. That ABI spec has been superseded generally by https://www.polyomino.org.uk/publications/2011/Power-Arch-32-bit-ABI-supp-1.0-Unified.pdf, which unifies that with the Linux ABI(s) and embedded ABI(s). That also includes the secure-PLT reference.

Your overall understanding of the relocations involved and code generated is accurate. To answer your questions:

• Newer linkers (GNU ld post-2.17.50) might be smart enough to convert to a local call. However, GNU ld uses PLTREL relocations without the +0x8000 offset as an indicator of "BSS-PLT" in its heuristics. This is what led to this change.
• It is an error to not use a PLTREL relocation for a call that needs to be indirected through the PLT. The linker will complain to recompile with -fPIC.

[MaskRay]

In D70570#1777712, @sfertile wrote:

Hi Justin,

I'd like to help reviewing this patch. I know how calls work in the 2 64-bit ELF abis pretty well but am not familiar with 32-bit PowerPC at all so I have a handful of questions to start:

1. I've been using this ABI DOC. Is this the 32-bit ABI supported in LLVM? Are there other 32-bit ELF PowerPC Abis I need to be aware of?
2. What secure-plt reference or references should I read to get up to speed?

Power Architecture® 32-bit Application Binary Interface Supplement 1.0 - Linux® & Embedded (https://www.polyomino.org.uk/publications/2011/Power-Arch-32-bit-ABI-supp-1.0-Unified.pdf) is the newest version I can find. You can find secure PLT information there. Unfortunately I think a lot of details are undocumented. They are essentially implementation details in gcc and binutils, so we have to observe gcc/as/ld output or read their source code.

@jhibbits This patch needs a rebase after D70126.

Finally I'd like to just verify my base understanding of the difference between bl sym and bl sym@PLT.

bl sym will produce a call instruction with an R_PPC_REL24 relocation, which will tell the linker to fill in the instruction with the offset from the program counter at the call instruction to sym.

Matches my observations.

bl sym@PLT will produce a call instruction with an R_PPC_PLTREL24 which will instruct the linker to create a PLT, allocate a PLT entry for sym, and fill in the instruction with the offset from the program counter to the PLT entry for 'sym'.

This is like R_X86_64_PLT32. A PLT entry may be optimized out if it is not necessary (the symbol is non-preemptible). See

// lld/ELF/Relocations.cpp
static RelExpr fromPlt(RelExpr expr) {
  // We decided not to use a plt. Optimize a reference to the plt to a
  // reference to the symbol itself.
  switch (expr) {
  case R_PLT_PC:
  case R_PPC32_PLTREL:
    return R_PC;

The tricky part is that the addend may be 0 (BSS-PLT or Secure-PLT -fpic/-fpie) or 0x8000 (Secure-PLT -fPIC/-fPIE).

As an aside: https://reviews.llvm.org/D70937 was committed to fix PPC64 problems, but we need to think how to make the code more general (less PPC32 specific hack).

I'm used to having 1 relocation type for both calls, and the linker can determine based on the properties of 'sym' and whether its linking a shared object or not whether the call needs to indirect through the PLT.

• If you emit a call instruction with the PLTREL relocation but the symbol ends up module local, does the linker convert the call to a local one?

It does.

• Is it an error to not use a PLTREL relocation for a call that needs to be indirected through the PLT or is the linker smart enough to add a PLT entry for the symbol and branch to there instead?

For Secure PLT -fPIC/-fPIE which uses 0x8000 as the addend of an R_PPC_PLTREL24 relocation, R_PPC_PLTREL24 must be used. It is an error in GNU ld and lld to use R_PPC_REL24.

[sfertile]

@MaskRay , @jhibbits Thank you for providing the correct ABI doc, and for the answers. I'll start going through it.

In D70570#1777864, @jhibbits wrote:

@Bdragon28 we might need to use -mlongcall for modules, if we aren't already. This should(?) force the compiler to generate the appropriate long-distance code sequences. I'm not sure, though, if clang supports this yet.

Clang does support it, there is a test test/Driver/ppc-features.cpp. Only calls where the callee is a GlobalAddressSDNode are transformed though. ExternalSymbolSDNode callees might need to be transformed as well: For example I believe the selection dag can create calls to memcpy/memset/memmove where the callee is an ExternalSymbolSDNode. Is transforming every call into a direct call overkill though? Would it be possible to perform a direct all to any local callee, and indirect calls for external symbols?

IIUC this patch is a pretty drastic change. Take fopr example the following IR:

target datalayout = "E-m:e-p:32:32-i64:64-n32"
target triple = "powerpc-unknown-linux-gnu-unknown"

@Dst = external global [512 x i32], align 4
@Src = external global [512 x i32], align 4
define dso_local void @caller(i32 %i) local_unnamed_addr {
entry:
  %call = tail call i8* @memcpy(i8* bitcast ([512 x i32]* @Dst to i8*), i8* bitcast ([512 x i32]* @Src to i8*), i32 %i)
  ret void
}
declare i8* @memcpy(i8*, i8*, i32) local_unnamed_addr

!llvm.module.flags = !{!0}
!0 = !{i32 1, !"wchar_size", i32 4}

Will now produce: bl memcpy instead of bl memcpy@PLT

Combined with:

In D70570#1777864, @jhibbits wrote:

• It is an error to not use a PLTREL relocation for a call that needs to be indirected through the PLT. The linker will complain to recompile with -fPIC.

Means you can't link static execs against shared objects anymore. Is this the intent? Or am I missing something obvious?

[jhibbits]

In D70570#1778165, @sfertile wrote:

@MaskRay , @jhibbits Thank you for providing the correct ABI doc, and for the answers. I'll start going through it.

In D70570#1777864, @jhibbits wrote:

• It is an error to not use a PLTREL relocation for a call that needs to be indirected through the PLT. The linker will complain to recompile with -fPIC.

Means you can't link static execs against shared objects anymore. Is this the intent? Or am I missing something obvious?

My phrasing wasn't quite right, I guess.
The linker will create the PLT stubs by nature of it being an external shared object, or something to that effect. What I really meant was that it's an error to need a PLT and not have it (linker will warn or error if you try to create a .so and use anything other than PLTREL relocations).

[sfertile]

In D70570#1778180, @jhibbits wrote:

In D70570#1778165, @sfertile wrote:

In D70570#1777864, @jhibbits wrote:

• It is an error to not use a PLTREL relocation for a call that needs to be indirected through the PLT. The linker will complain to recompile with -fPIC.

Means you can't link static execs against shared objects anymore. Is this the intent? Or am I missing something obvious?

My phrasing wasn't quite right, I guess.
The linker will create the PLT stubs by nature of it being an external shared object, or something to that effect. What I really meant was that it's an error to need a PLT and not have it (linker will warn or error if you try to create a .so and use anything other than PLTREL relocations).

Ok, that makes sense then.

Like MaskRay mentioned previously, you will have to rebase this as there was a pretty large refactor that landed to the call lowering code.

[jhibbits]

Rebase

[MaskRay]

Since I recently picked up some stuff on lld PPC32, I have run powerpc-linux-gnu-gcc many times to observe its behaviors. This matches what I see, but you probably also need @sfertile's thumbs-up.

because it breaks secure-PLT linking with GNU LD

Can you be more specific? I guess this is because clang emitted R_PPC_PLTREL24 causes GNU ld to fall back to --bss-plt due to a deficiency in its bfd/elf32-ppc.c:ppc_elf_select_plt_layout code.

powerpc-linux-gnu-ld: bss-plt forced due to b.o

[sfertile]

LGTM also. I have one minor question: Is it worthwhile to add a small lit test explicitly for this? ie.

1. we don't emit the '@PLT' annotation on a call when linking with static-relocation model.
2. emit the annotation with PIC relocation model.

That gives us somewhere a bit more visible you can add the comment about how emitting the annotation for static relocation model breaks secure-plt linking with ld.bfd.

[jhibbits]

Update diff. It would help if I actually compiled when rebasing...

@sfertile I figured the available-externally.ll test would suffice for this.
Do you think a separate test is needed, or a comment is warranted on this
test for it?

[sfertile]

In D70570#1789789, @jhibbits wrote:

Update diff. It would help if I actually compiled when rebasing...

@sfertile I figured the available-externally.ll test would suffice for this.
Do you think a separate test is needed, or a comment is warranted on this
test for it?

I see the available externally test more as a test of that specific linkage type, but anyone that tried to update this behavior would need to modify that test, and see the comment so I'd be equally happy with either.

[sfertile]

llvm/lib/Target/PowerPC/PPCISelLowering.cpp

5110–5116

Minor nit: I belive clang-format will produce a different indentation for this. can you run that before committing.

[jhibbits]

Updated diff after clang-format. I actually had run git-clang-format on it
before submitting, but forgot to amend it to the change before submitting
for review.

llvm/lib/Target/PowerPC/PPCISelLowering.cpp

static SDValue transformCallee(const SDValue &Callee, SelectionDAG &DAG,
   auto isLocalCallee = [&]() {
     const GlobalAddressSDNode *G = dyn_cast<GlobalAddressSDNode>(Callee);
     const Module *Mod = DAG.getMachineFunction().getFunction().getParent();
 
     return DAG.getTarget().shouldAssumeDSOLocal(*Mod,
                                                 G ? G->getGlobal() : nullptr);
   };
 
-  bool UsePlt = Subtarget.is32BitELFABI() && !isLocalCallee();
+  // The PLT is only used in 32-bit ELF PIC mode.  Attempting to use the PLT in
+  // a static relocation model causes some versions of GNU LD (2.17.50, at
+  // least) to force BSS-PLT, instead of secure-PLT, even if all objects are
+  // built with secure-PLT.
+  bool UsePlt =
+      Subtarget.is32BitELFABI() && !isLocalCallee() &&
+      Subtarget.getTargetMachine().getRelocationModel() == Reloc::PIC_;
 
   if (isFunctionGlobalAddress(Callee)) {
     const GlobalAddressSDNode *G = cast<GlobalAddressSDNode>(Callee);
     if (!Subtarget.isAIXABI())
       return DAG.getTargetGlobalAddress(G->getGlobal(), dl,
                                         Callee.getValueType(), 0,
                                         UsePlt ? PPCII::MO_PLT : 0);
 

llvm/test/CodeGen/PowerPC/2008-10-28-f128-i32.ll

 ; CHECK-NEXT:    lwz 3, 300(1)
 ; CHECK-NEXT:    lfd 31, 320(1)
 ; CHECK-NEXT:    stw 3, 316(1)
 ; CHECK-NEXT:    fmr 1, 31
 ; CHECK-NEXT:    lwz 3, 296(1)
 ; CHECK-NEXT:    stw 3, 312(1)
 ; CHECK-NEXT:    lfd 30, 312(1)
 ; CHECK-NEXT:    fmr 2, 30
-; CHECK-NEXT:    bl __gcc_qmul@PLT
+; CHECK-NEXT:    bl __gcc_qmul
 ; CHECK-NEXT:    lis 3, 16864
 ; CHECK-NEXT:    stfd 1, 280(1)
 ; CHECK-NEXT:    stw 3, 368(1)
 ; CHECK-NEXT:    stfd 2, 288(1)
 ; CHECK-NEXT:    stw 29, 372(1)
 ; CHECK-NEXT:    stw 29, 364(1)
 ; CHECK-NEXT:    stw 29, 360(1)
 ; CHECK-NEXT:    fmr 29, 1
 ; CHECK-NEXT:    lwz 3, 284(1)
 ; CHECK-NEXT:    fmr 28, 2
 ; CHECK-NEXT:    lfd 3, 368(1)
 ; CHECK-NEXT:    lfd 4, 360(1)
 ; CHECK-NEXT:    stw 3, 356(1)
 ; CHECK-NEXT:    lwz 3, 280(1)
 ; CHECK-NEXT:    stw 3, 352(1)
 ; CHECK-NEXT:    lwz 3, 292(1)
 ; CHECK-NEXT:    lfd 1, 352(1)
 ; CHECK-NEXT:    stw 3, 348(1)
 ; CHECK-NEXT:    lwz 3, 288(1)
 ; CHECK-NEXT:    stw 3, 344(1)
 ; CHECK-NEXT:    lfd 2, 344(1)
-; CHECK-NEXT:    bl __gcc_qsub@PLT
+; CHECK-NEXT:    bl __gcc_qsub
 ; CHECK-NEXT:    mffs 0
 ; CHECK-NEXT:    mtfsb1 31
 ; CHECK-NEXT:    lis 3, .LCPI0_1@ha
 ; CHECK-NEXT:    fcmpu 0, 28, 27
 ; CHECK-NEXT:    mtfsb0 30
 ; CHECK-NEXT:    fadd 1, 2, 1
 ; CHECK-NEXT:    mtfsf 1, 0
 ; CHECK-NEXT:    fctiwz 0, 1

 ; CHECK-NEXT:  # %bb.3: # %bb1
 ; CHECK-NEXT:    ori 30, 4, 0
 ; CHECK-NEXT:    b .LBB0_5
 ; CHECK-NEXT:  .LBB0_4: # %bb1
 ; CHECK-NEXT:    addi 30, 3, 0
 ; CHECK-NEXT:  .LBB0_5: # %bb1
 ; CHECK-NEXT:    li 4, 0
 ; CHECK-NEXT:    mr 3, 30
-; CHECK-NEXT:    bl __floatditf@PLT
+; CHECK-NEXT:    bl __floatditf
 ; CHECK-NEXT:    lis 3, 17392
 ; CHECK-NEXT:    stfd 1, 208(1)
 ; CHECK-NEXT:    stw 3, 240(1)
 ; CHECK-NEXT:    stfd 2, 200(1)
 ; CHECK-NEXT:    stw 29, 244(1)
 ; CHECK-NEXT:    stw 29, 236(1)
 ; CHECK-NEXT:    stw 29, 232(1)
 ; CHECK-NEXT:    fmr 29, 1
 ; CHECK-NEXT:    lwz 3, 212(1)
 ; CHECK-NEXT:    fmr 28, 2
 ; CHECK-NEXT:    lfd 3, 240(1)
 ; CHECK-NEXT:    lfd 4, 232(1)
 ; CHECK-NEXT:    cmpwi 2, 30, 0
 ; CHECK-NEXT:    stw 3, 228(1)
 ; CHECK-NEXT:    lwz 3, 208(1)
 ; CHECK-NEXT:    stw 3, 224(1)
 ; CHECK-NEXT:    lwz 3, 204(1)
 ; CHECK-NEXT:    lfd 1, 224(1)
 ; CHECK-NEXT:    stw 3, 220(1)
 ; CHECK-NEXT:    lwz 3, 200(1)
 ; CHECK-NEXT:    stw 3, 216(1)
 ; CHECK-NEXT:    lfd 2, 216(1)
-; CHECK-NEXT:    bl __gcc_qadd@PLT
+; CHECK-NEXT:    bl __gcc_qadd
 ; CHECK-NEXT:    blt 2, .LBB0_7
 ; CHECK-NEXT:  # %bb.6: # %bb1
 ; CHECK-NEXT:    fmr 2, 28
 ; CHECK-NEXT:  .LBB0_7: # %bb1
 ; CHECK-NEXT:    blt 2, .LBB0_9
 ; CHECK-NEXT:  # %bb.8: # %bb1
 ; CHECK-NEXT:    fmr 1, 29
 ; CHECK-NEXT:  .LBB0_9: # %bb1
 ; CHECK-NEXT:    stfd 1, 184(1)
 ; CHECK-NEXT:    stfd 2, 192(1)
 ; CHECK-NEXT:    fmr 1, 31
 ; CHECK-NEXT:    lwz 3, 188(1)
 ; CHECK-NEXT:    fmr 2, 30
 ; CHECK-NEXT:    stw 3, 260(1)
 ; CHECK-NEXT:    lwz 3, 184(1)
 ; CHECK-NEXT:    stw 3, 256(1)
 ; CHECK-NEXT:    lwz 3, 196(1)
 ; CHECK-NEXT:    lfd 3, 256(1)
 ; CHECK-NEXT:    stw 3, 252(1)
 ; CHECK-NEXT:    lwz 3, 192(1)
 ; CHECK-NEXT:    stw 3, 248(1)
 ; CHECK-NEXT:    lfd 4, 248(1)
-; CHECK-NEXT:    bl __gcc_qsub@PLT
+; CHECK-NEXT:    bl __gcc_qsub
 ; CHECK-NEXT:    stfd 2, 176(1)
 ; CHECK-NEXT:    stfd 1, 168(1)
 ; CHECK-NEXT:    fcmpu 1, 2, 27
 ; CHECK-NEXT:    lwz 3, 180(1)
 ; CHECK-NEXT:    fcmpu 0, 1, 27
 ; CHECK-NEXT:    crandc 20, 2, 4
 ; CHECK-NEXT:    stw 3, 268(1)
 ; CHECK-NEXT:    lwz 3, 176(1)

 ; CHECK-NEXT:    lwz 3, 48(1)
 ; CHECK-NEXT:    stw 3, 64(1)
 ; CHECK-NEXT:    lwz 3, 44(1)
 ; CHECK-NEXT:    lfd 1, 64(1)
 ; CHECK-NEXT:    stw 3, 60(1)
 ; CHECK-NEXT:    lwz 3, 40(1)
 ; CHECK-NEXT:    stw 3, 56(1)
 ; CHECK-NEXT:    lfd 2, 56(1)
-; CHECK-NEXT:    bl __gcc_qsub@PLT
+; CHECK-NEXT:    bl __gcc_qsub
 ; CHECK-NEXT:    mffs 0
 ; CHECK-NEXT:    mtfsb1 31
 ; CHECK-NEXT:    lis 3, .LCPI0_2@ha
 ; CHECK-NEXT:    mtfsb0 30
 ; CHECK-NEXT:    fadd 1, 2, 1
 ; CHECK-NEXT:    mtfsf 1, 0
 ; CHECK-NEXT:    fctiwz 0, 1
 ; CHECK-NEXT:    mffs 1

 ; CHECK-NEXT:    lwz 3, 112(1)
 ; CHECK-NEXT:    stw 3, 128(1)
 ; CHECK-NEXT:    lwz 3, 108(1)
 ; CHECK-NEXT:    lfd 1, 128(1)
 ; CHECK-NEXT:    stw 3, 124(1)
 ; CHECK-NEXT:    lwz 3, 104(1)
 ; CHECK-NEXT:    stw 3, 120(1)
 ; CHECK-NEXT:    lfd 2, 120(1)
-; CHECK-NEXT:    bl __gcc_qsub@PLT
+; CHECK-NEXT:    bl __gcc_qsub
 ; CHECK-NEXT:    mffs 0
 ; CHECK-NEXT:    mtfsb1 31
 ; CHECK-NEXT:    lis 3, .LCPI0_0@ha
 ; CHECK-NEXT:    mtfsb0 30
 ; CHECK-NEXT:    fadd 1, 2, 1
 ; CHECK-NEXT:    mtfsf 1, 0
 ; CHECK-NEXT:    fctiwz 0, 1
 ; CHECK-NEXT:    mffs 1

llvm/test/CodeGen/PowerPC/2010-02-12-saveCR.ll

 ; RUN: llc -verify-machineinstrs < %s -mtriple=powerpc-unknown-linux-gnu -break-anti-dependencies=none | FileCheck %s
 ; ModuleID = 'hh.c'
 ;;;;; target datalayout = "E-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f128:64:128-n32"
 target triple = "powerpc-unknown-linux-gnu.6"
 
 define void @foo() nounwind {
 entry:
 ; Note that part of what is being checked here is proper register reuse.
 ; CHECK: mfcr [[T1:[0-9]+]]
 ; CHECK-DAG: subf 0, 0, 1
 ; CHECK-DAG: ori [[T2:[0-9]+]], [[T2]], 34492
 ; CHECK-DAG: stwx [[T1]], 1, [[T2]]
 ; CHECK-DAG: addi 3, 1, 28
-; CHECK: bl bar@PLT
+; CHECK: bl bar
   %x = alloca [100000 x i8]                       ; <[100000 x i8]*> [#uses=1]
   %"alloca point" = bitcast i32 0 to i32          ; <i32> [#uses=0]
   %x1 = bitcast [100000 x i8]* %x to i8*          ; <i8*> [#uses=1]
   call void @bar(i8* %x1) nounwind
   call void asm sideeffect "", "~{cr2},~{cr3}"() nounwind
   br label %return
 
 return:                                           ; preds = %entry
 ; CHECK: ori [[T2]], [[T2]], 34492
 ; CHECK: lwzx [[T1]], 1, [[T2]]
 ; CHECK: mtcrf 32, [[T1]]
 ; CHECK: mtcrf 16, [[T1]]
   ret void
 }
 
 declare void @bar(i8*)

llvm/test/CodeGen/PowerPC/available-externally.ll

+; RUN: llc -verify-machineinstrs < %s | FileCheck %s -check-prefix=STATIC
 ; RUN: llc -verify-machineinstrs < %s -relocation-model=static | FileCheck %s -check-prefix=STATIC
 ; RUN: llc -verify-machineinstrs < %s -relocation-model=pic -mtriple=powerpc-unknown-linux-gnu | FileCheck %s -check-prefix=PIC
 ; RUN: llc -verify-machineinstrs < %s -relocation-model=pic -mtriple=powerpc-unknown-linux | FileCheck %s -check-prefix=PICELF
 ; RUN: llc -verify-machineinstrs < %s -relocation-model=pic -mtriple=powerpc64-unknown-linux-gnu | FileCheck %s -check-prefix=PIC64
 
 ;;; KB: These two tests currently cause an assertion. It seems as though we cannot have a non DSOLocal symbol with dynamic-no-pic.
 ;;;     I need to ask Sean about this.
 ;;; RUN-NOT: llc -verify-machineinstrs < %s -relocation-model=dynamic-no-pic -mtriple=powerpc-unknown-linux-gnu | FileCheck %s -check-prefix=DYNAMIC
 ;;; RUN-NOT: llc -verify-machineinstrs < %s -relocation-model=dynamic-no-pic -mtriple=powerpc64-unknown-linux-gnu | FileCheck %s -check-prefix=DYNAMIC64
 ; PR4482
 target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:128:128"
 target triple = "powerpc-unknown-linux-gnu"
 
 define i32 @foo(i64 %x) nounwind {
 entry:
 ; STATIC: foo:
-; STATIC: bl exact_log2@PLT
+; STATIC: bl exact_log2
 ; STATIC: blr
 
 ; PIC: foo:
 ; PIC: bl exact_log2@PLT
 ; PIC: blr
 
 ; PICELF: foo:
 ; PICELF: bl exact_log2@PLT

llvm/test/CodeGen/PowerPC/srem-lkk.ll

 ; CHECK:       # %bb.0:
 ; CHECK-NEXT:    mflr 0
 ; CHECK-NEXT:    stw 0, 4(1)
 ; CHECK-NEXT:    stwu 1, -16(1)
 ; CHECK-NEXT:    .cfi_def_cfa_offset 16
 ; CHECK-NEXT:    .cfi_offset lr, 4
 ; CHECK-NEXT:    li 5, 0
 ; CHECK-NEXT:    li 6, 98
-; CHECK-NEXT:    bl __moddi3@PLT
+; CHECK-NEXT:    bl __moddi3
 ; CHECK-NEXT:    lwz 0, 20(1)
 ; CHECK-NEXT:    addi 1, 1, 16
 ; CHECK-NEXT:    mtlr 0
 ; CHECK-NEXT:    blr
   %1 = srem i64 %x, 98
   ret i64 %1
 }

llvm/test/CodeGen/PowerPC/stubs.ll

 ; RUN: llc -verify-machineinstrs %s -o - -mtriple=powerpc-unknown-linux-gnu | FileCheck %s
 define ppc_fp128 @test1(i64 %X) nounwind readnone {
 entry:
   %0 = sitofp i64 %X to ppc_fp128
   ret ppc_fp128 %0
 }
 
 ; CHECK: test1:
-; CHECK: bl __floatditf@PLT
+; CHECK: bl __floatditf

llvm/test/CodeGen/PowerPC/umulo-128-legalisation-lowering.ll

 ; PPC32-NEXT:    stw 24, 48(1) # 4-byte Folded Spill
 ; PPC32-NEXT:    stw 25, 52(1) # 4-byte Folded Spill
 ; PPC32-NEXT:    stw 28, 64(1) # 4-byte Folded Spill
 ; PPC32-NEXT:    mr 25, 10
 ; PPC32-NEXT:    stw 12, 28(1)
 ; PPC32-NEXT:    mr 28, 9
 ; PPC32-NEXT:    mr 23, 6
 ; PPC32-NEXT:    mr 24, 5
-; PPC32-NEXT:    bl __multi3@PLT
+; PPC32-NEXT:    bl __multi3
 ; PPC32-NEXT:    mr 7, 4
 ; PPC32-NEXT:    mullw 4, 24, 30
 ; PPC32-NEXT:    mullw 8, 29, 23
 ; PPC32-NEXT:    mullw 10, 28, 27
 ; PPC32-NEXT:    mullw 11, 26, 25
 ; PPC32-NEXT:    mulhwu 9, 30, 23
 ; PPC32-NEXT:    mulhwu 12, 27, 25
 ; PPC32-NEXT:    mullw 0, 30, 23

llvm/test/CodeGen/PowerPC/urem-lkk.ll

 ; CHECK:       # %bb.0:
 ; CHECK-NEXT:    mflr 0
 ; CHECK-NEXT:    stw 0, 4(1)
 ; CHECK-NEXT:    stwu 1, -16(1)
 ; CHECK-NEXT:    .cfi_def_cfa_offset 16
 ; CHECK-NEXT:    .cfi_offset lr, 4
 ; CHECK-NEXT:    li 5, 0
 ; CHECK-NEXT:    li 6, 98
-; CHECK-NEXT:    bl __umoddi3@PLT
+; CHECK-NEXT:    bl __umoddi3
 ; CHECK-NEXT:    lwz 0, 20(1)
 ; CHECK-NEXT:    addi 1, 1, 16
 ; CHECK-NEXT:    mtlr 0
 ; CHECK-NEXT:    blr
   %1 = urem i64 %x, 98
   ret i64 %1
 }