[AArch64] Optimise load(adr address) to ldr address

[dmgreen]

Summary

Providing that the load is known to be 4 byte aligned, we can optimise a ldr(adr address) to just ldr address.

[dmgreen]

Unfortunately I'm hitting a number of linker problems in testing this.

• Armlink seems to do fine, but I am testing embedded code there.
• ld.bfd links the test-suite fine with fpic (except for the expected errors where relocations are out of range). But without pic gives an error about relocating against stderr that I'm not sure of yet, but might point to this alignment check being wrong in some way. Unfortunately the errors are not clear what is out of range, it may be a legitimate error (although ld.gold and lld both are "successful" at linking the same program).
• ld.gold doesn't like load literal relocations, producing invalid instructions.
• lld, with some extra patches, does fine for anything that isn't a tls relocation I think.

[peter.smith]

In D51030#1207255, @dmgreen wrote:

Unfortunately I'm hitting a number of linker problems in testing this.

• Armlink seems to do fine, but I am testing embedded code there.
• ld.bfd links the test-suite fine with fpic (except for the expected errors where relocations are out of range). But without pic gives an error about relocating against stderr that I'm not sure of yet, but might point to this alignment check being wrong in some way. Unfortunately the errors are not clear what is out of range, it may be a legitimate error (although ld.gold and lld both are "successful" at linking the same program).

Some thoughts:

• When compiling PIC I'm guessing that the reference to stderr will go via the GOT, this is likely to be closer to the code than the data.
• I can't see anything obviously wrong with the BFD code for handling LO19
• LLD has a different section layout to BFD, in particular it puts the ro-data before code so it may be just luck that puts stderr in range for LLD. You may be able to reproduce by feeding LLD the ld.bfd linker map file.
• One way to find out whether the out of range error is correct is to use the small code model and see how big the distance between stderr and the equivalent place in the relocation is. Accounting for the tiny code model, does this look credible?

• ld.gold doesn't like load literal relocations, producing invalid instructions.

I think it will be worth filing a binutils bug, a quick check of the entry for aarch64-reloc.def in gold shows us:

ARD(LD_PREL_LO19		 , STATIC ,  AARCH64    ,   Y,  -1,   20,20		  ,    2,20 , Symbol::RELATIVE_REF , 			     LDST  )

with the LDST being the key part. I think that should be LD as there isn't a store literal and the LDST category of relocations have a different set of encoding rules.

• lld, with some extra patches, does fine for anything that isn't a tls relocation I think.

If there is anything I can do to help here let me know?

[dmgreen]

In D51030#1207378, @peter.smith wrote:

• I can't see anything obviously wrong with the BFD code for handling LO19

Trying a newer ld.bfd (2.31 from today) this is working fine in both modes, so perhaps the issue is old. It was 2.27/2.28 that I was trying earlier, but the program being compiled (timeit-target) is small enough that I didn't expect it to go out of range.

I think it will be worth filing a binutils bug, a quick check of the entry for aarch64-reloc.def in gold shows us:

https://sourceware.org/bugzilla/show_bug.cgi?id=23557

If there is anything I can do to help here let me know?

I think the tls problems was me getting the code to add R_AARCH64_GOT_LD_PREL19 and R_AARCH64_TLSIE_LD_GOTTPREL_PREL19 relocations incorrect. GOT seems easy enough now I've figured out what was wrong, TLSIE I'm not sure about yet but I'm guessing it should be possible.

[peter.smith]

In D51030#1207898, @dmgreen wrote:

In D51030#1207378, @peter.smith wrote:

• I can't see anything obviously wrong with the BFD code for handling LO19

Trying a newer ld.bfd (2.31 from today) this is working fine in both modes, so perhaps the issue is old. It was 2.27/2.28 that I was trying earlier, but the program being compiled (timeit-target) is small enough that I didn't expect it to go out of range.

I can reproduce with the installed binutils on Ubuntu 16.04 (2.26.1). Taking a look at the object that causes the problem the specific error message I see is

get.dir/timeit.c.o  -o timeit-target 
/usr/bin/ld: CMakeFiles/timeit-target.dir/timeit.c.o(.text+0x5dc): unresolvable R_AARCH64_LD_PREL_LO19 relocation against symbol `stderr@@GLIBC_2.17'

I think that this is likely to be the only time in the test suite that there is a R_AARCH64_LD_PREL_LO19 to a data symbol in a shared library. In theory this should generate a R_AARCH64_COPY dynamic relocation. I think that this was fixed as part of the changes made in https://sourceware.org/bugzilla/show_bug.cgi?id=21532 "[AArch64] Allow COPY relocation elimination" as prior to that R_AARCH64_LD_PREL_LO19 wasn't in the switch statement to generate copy relocations. The change made it into binutils 2.29.

If there is anything I can do to help here let me know?

I think the tls problems was me getting the code to add R_AARCH64_GOT_LD_PREL19 and R_AARCH64_TLSIE_LD_GOTTPREL_PREL19 relocations incorrect. GOT seems easy enough now I've figured out what was wrong, TLSIE I'm not sure about yet but I'm guessing it should be possible.

I'm guessing that this is the relaxation from TLSIE to TLSLE? I think that will be possible as it should be possible to tell from the relocation at the place which code model is being used.

[john.brawn]

lib/Target/AArch64/AArch64ISelDAGToDAG.cpp

1098

I'm pretty sure we can do the selection entirely in tablegen. I experimented with adjusting LoadLiteral AArch64InstrFormats.td to be kinda similar to Load32RO (take ValueType and SDPatternOperator as arguments, use these in a pattern but match AArch64adr for the address) and that seemed to work. The only problem there is making sure the alignment is correct, which I think can be done using a PatFrag or PatLeaf (though I tried something quick and ran into tablegen errors, so maybe it's more complicated than I expect).

[dmgreen]

In D51030#1209332, @peter.smith wrote:

I think that this is likely to be the only time in the test suite that there is a R_AARCH64_LD_PREL_LO19 to a data symbol in a shared library. In theory this should generate a R_AARCH64_COPY dynamic relocation. I think that this was fixed as part of the changes made in https://sourceware.org/bugzilla/show_bug.cgi?id=21532 "[AArch64] Allow COPY relocation elimination" as prior to that R_AARCH64_LD_PREL_LO19 wasn't in the switch statement to generate copy relocations. The change made it into binutils 2.29.

Thanks for looking. What is our usual response with issues like this? Is it OK for this to go ahead, as it can be used fine in some linkers. I could put it behind a flag I think, so that users have the option to turn it off (although that might not be very obvious..)

I'm guessing that this is the relaxation from TLSIE to TLSLE? I think that will be possible as it should be possible to tell from the relocation at the place which code model is being used.

Yep :)

lib/Target/AArch64/AArch64ISelDAGToDAG.cpp

1098

Yep, my original version of this was just in tablegen. I wasn't sure about how to do the alignment though, and it seemed to need an addedcomplexity of at least 20, at least the way I did it.

I'll try and take another go at doing it there, so long as it can handle the alignment and all the LDRSWl/LDRXl/LDRWl's. I'll let you know how it looks.

[peter.smith]

Thanks for looking. What is our usual response with issues like this? Is it OK for this to go ahead, as it can be used fine in some linkers. I could put it behind a flag I think, so that users have the option to turn it off (although that might not be very obvious..)

I think it depends on the context. For example:

• How many existing builds is it going to break?
• How easy would it be to backport the fix in binutils if it were important enough to do so?
• Are there alternatives to binutils available?
• Does the same fault exist when compiling the file with GCC?

In this particular case I think:

• There are no existing clients of the tiny code model, so no existing builds to break.
• The fix is fairly recent, AArch64 specific so it could be backported if necessary.
• In theory LLD is an option if we get support in for the same clang release.
• If it doesn't work on GCC it probably means very few people are using the feature on linux.

In summary I think the impact would be low enough that it isn't worth worrying about it.

[dmgreen]

Many tablegen crashes later.. :)

I wasn't sure if there was some better way to say "any address" than this.

[efriedma]

lib/Target/AArch64/AArch64InstrInfo.td

1896 ↗

(On Diff #162715)

Checking the alignment of the load isn't going to do the right thing in general; you need to check that the global is aligned. (Normally, a misaligned load is UB, but this would turn it into a link error.)

[dmgreen]

lib/Target/AArch64/AArch64InstrInfo.td

1896 ↗

(On Diff #162715)

OK thanks. Can you give more details on the difference? Is the load's alignment wrong or inefficient? Or do you mean that in the event that load's alignment is wrong in a way that is UB, it needs to not be link error?

I would expect if we had an aligned global, <something> (instsimplify maybe?) would set the alignment on the load to that of the global. And we are using the alignment for a ldr here, so it coming from a load at least makes sense in that way.

There are other examples of aligned load patterns like this, such as alignedload16 from arm or alignedload from x86. They may not be expecting to be acting on the same global data though.

[dmgreen]

"alignedAArch64adr"

It may be better to make this match the alignment on the global directly, not looking through the ADR. I'm not sure how that's done yet.

[efriedma]

lib/Target/AArch64/AArch64InstrInfo.td

1896 ↗

(On Diff #162715)

Or do you mean that in the event that load's alignment is wrong in a way that is UB, it needs to not be link error?

I mean this: we can't reliably prevent optimizations that clone code, like inlining, from introducing UB, so UB can't be a link error.

The requirement here is different from alignedload because normally aligned loads only fault (or load incorrect data) if you violate the alignment requirement; the code still links. For example, on x86, "movapd 1, %xmm0" is a valid instruction, even though it will always fault.

[efriedma]

lib/Target/AArch64/AArch64InstrInfo.td

1900 ↗

(On Diff #162926)

I'd suggest just using unsigned Align = G->getGlobal()->getPointerAlignment() here, which should reliably do the right thing for all GlobalObjects.

Should be possible to match a global address node directly using something like the following:

def alignedglobaladdr : PatLeaf<(tglobaladdr), [{
  auto *G = cast<GlobalAddressSDNode>(N);
  // etc.
}]>;

[dmgreen]

lib/Target/AArch64/AArch64InstrInfo.td

1900 ↗

(On Diff #162926)

Thanks for the suggestions. Will do.

I was looking for a way to avoid these multiple Pat's, having a PatLeaf that matched either tglobaladdr or tconstpool. You can let me know if it's worth it over multiple patterns.

1896 ↗

(On Diff #162715)

I see.

We currently use other ldr literal relocations, but I guess those are mostly to gotslots so cant be unaligned in the same way. I'm not sure about the tls ones, I think they all go through a got too.

[efriedma]

LGTM

[dmgreen]

Thanks.

lib/Target/AArch64/AArch64ISelDAGToDAG.cpp

public:
 
   /// Generic helper for the createDTuple/createQTuple
   /// functions. Those should almost always be called instead.
   SDValue createTuple(ArrayRef<SDValue> Vecs, const unsigned RegClassIDs[],
                       const unsigned SubRegs[]);
 
   void SelectTable(SDNode *N, unsigned NumVecs, unsigned Opc, bool isExt);
 
+  bool tryAdrLoad(SDNode *N);
   bool tryIndexedLoad(SDNode *N);
 
   void SelectLoad(SDNode *N, unsigned NumVecs, unsigned Opc,
                      unsigned SubRegIdx);
   void SelectPostLoad(SDNode *N, unsigned NumVecs, unsigned Opc,
                          unsigned SubRegIdx);
   void SelectLoadLane(SDNode *N, unsigned NumVecs, unsigned Opc);
   void SelectPostLoadLane(SDNode *N, unsigned NumVecs, unsigned Opc);
void AArch64DAGToDAGISel::SelectTable(SDNode *N, unsigned NumVecs, unsigned Opc,
   SmallVector<SDValue, 6> Ops;
   if (isExt)
     Ops.push_back(N->getOperand(1));
   Ops.push_back(RegSeq);
   Ops.push_back(N->getOperand(NumVecs + ExtOff + 1));
   ReplaceNode(N, CurDAG->getMachineNode(Opc, dl, VT, Ops));
 }
 
+bool AArch64DAGToDAGISel::tryAdrLoad(SDNode *N) {
+  // Look for a load(adr <addr>) where the addr is 4 byte aligned
+  assert(N->getOpcode() == ISD::LOAD &&
+         "N must be a LOAD operation to call this function");
+  LoadSDNode *LD = cast<LoadSDNode>(N);
+  EVT VT = LD->getMemoryVT();
+  EVT DstVT = N->getValueType(0);
+  if (!LD->isUnindexed())
+    return false;
+  if (VT != MVT::i32 && VT != MVT::i64)
+    return false;
+
+  SDValue Base = LD->getBasePtr();
+  if (Base.getNode()->getOpcode() != AArch64ISD::ADR)
+    return false;
+
+  assert(N->getOperand(2).getNode()->getOpcode() == ISD::UNDEF);
+
+  MachineMemOperand *MMO = LD->getMemOperand();
+  if (MMO->getAlignment() < 4)
+    return false;
+
+  SDLoc dl(N);
+  SDValue Addr = Base.getNode()->getOperand(0);
+  SDValue Ops[] = { Addr, LD->getChain() };
+
+  unsigned Opcode = 0;
+  ISD::LoadExtType ExtType = LD->getExtensionType();
+  bool InsertTo64 = false;
+  if (VT == MVT::i64)
+    Opcode = AArch64::LDRXl;
+  else if (ExtType == ISD::NON_EXTLOAD)
+    Opcode = AArch64::LDRWl;
+  else if (ExtType == ISD::SEXTLOAD)
+    Opcode = AArch64::LDRSWl;
+  else {
+    Opcode = AArch64::LDRWl;
+    InsertTo64 = true;
+    // The result of the load is only i32. It's the subreg_to_reg that makes
+    // it into an i64.
+    DstVT = MVT::i32;
+  }
+
+  SDNode *Res = CurDAG->getMachineNode(Opcode, dl, DstVT, MVT::Other, Ops);
+  CurDAG->setNodeMemRefs(cast<MachineSDNode>(Res), {MMO});
+
+  SDValue LoadedVal = SDValue(Res, 0);
+  if (InsertTo64) {
+    SDValue SubReg = CurDAG->getTargetConstant(AArch64::sub_32, dl, MVT::i32);
+    LoadedVal =
+        SDValue(CurDAG->getMachineNode(
+                    AArch64::SUBREG_TO_REG, dl, MVT::i64,
+                    CurDAG->getTargetConstant(0, dl, MVT::i64), LoadedVal,
+                    SubReg),
+                0);
+  }
+
+  ReplaceUses(SDValue(N, 0), LoadedVal);
+  ReplaceUses(SDValue(N, 1), SDValue(Res, 1));
+  CurDAG->RemoveDeadNode(N);
+  return true;
+}
+
 bool AArch64DAGToDAGISel::tryIndexedLoad(SDNode *N) {
   LoadSDNode *LD = cast<LoadSDNode>(N);
   if (LD->isUnindexed())
     return false;
   EVT VT = LD->getMemoryVT();
   EVT DstVT = N->getValueType(0);
   ISD::MemIndexedMode AM = LD->getAddressingMode();
   bool IsPre = AM == ISD::PRE_INC || AM == ISD::PRE_DEC;
case ISD::WRITE_REGISTER:
     break;
 
   case ISD::ADD:
     if (tryMLAV64LaneV128(Node))
       return;
     break;
 
   case ISD::LOAD: {
+    // Try to match load (adr global) -> ldr global
+    if (tryAdrLoad(Node))
+      return;
     // Try to select as an indexed load. Fall through to normal processing
     // if we can't.
     if (tryIndexedLoad(Node))
       return;
     break;
   }
 
   case ISD::SRL:

test/CodeGen/AArch64/code-model-tiny-abs.ll

 ; CHECK: adr x[[ADDR_REG:[0-9]+]], var16
 ; CHECK: ldrh w0, [x[[ADDR_REG]]]
 }
 
 define i32 @global_i32() {
 ; CHECK-LABEL: global_i32:
   %val = load i32, i32* @var32
   ret i32 %val
-; CHECK: adr x[[ADDR_REG:[0-9]+]], var32
-; CHECK: ldr w0, [x[[ADDR_REG]]]
+; CHECK: ldr w0, var32
 }
 
 define i64 @global_i64() {
 ; CHECK-LABEL: global_i64:
   %val = load i64, i64* @var64
   ret i64 %val
-; CHECK: adr x[[ADDR_REG:[0-9]+]], var64
-; CHECK: ldr x0, [x[[ADDR_REG]]]
+; CHECK: ldr x0, var64
 }
 
 define <2 x i64> @constpool() {
 ; CHECK-LABEL: constpool:
   ret <2 x i64> <i64 123456789, i64 987654321100>
 
 ; CHECK: adr x[[ADDR_REG:[0-9]+]], {{.LCPI[0-9]+_[0-9]+}}
 ; CHECK: ldr q0, [x[[ADDR_REG]]]
 }

test/CodeGen/AArch64/ldradr.ll

+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc < %s -mtriple=aarch64-none-eabi -code-model=tiny -verify-machineinstrs | FileCheck %s
+
+%struct.T = type <{ i32, i64, i8, i32 }>
+
+@ptr = external local_unnamed_addr global i32*, align 8
+@ch = external local_unnamed_addr global i32, align 4
+@t = external local_unnamed_addr global %struct.T, align 4
+@t2 = external local_unnamed_addr global %struct.T, align 2
+
+define i32 @barp() {
+; CHECK-LABEL: barp:
+; CHECK:       // %bb.0: // %entry
+; CHECK-NEXT:    ldr x8, ptr
+; CHECK-NEXT:    ldr w0, [x8]
+; CHECK-NEXT:    ret
+entry:
+  %0 = load i32*, i32** @ptr, align 8
+  %1 = load i32, i32* %0, align 4
+  ret i32 %1
+}
+
+define i32 @barch() {
+; CHECK-LABEL: barch:
+; CHECK:       // %bb.0: // %entry
+; CHECK-NEXT:    ldr w0, ch
+; CHECK-NEXT:    ret
+entry:
+  %0 = load i32, i32* @ch, align 4
+  ret i32 %0
+}
+
+define i32 @barta() {
+; CHECK-LABEL: barta:
+; CHECK:       // %bb.0: // %entry
+; CHECK-NEXT:    ldr w0, t
+; CHECK-NEXT:    ret
+entry:
+  %0 = load i32, i32* getelementptr inbounds (%struct.T, %struct.T* @t, i64 0, i32 0), align 4
+  ret i32 %0
+}
+
+define i64 @bartb() {
+; CHECK-LABEL: bartb:
+; CHECK:       // %bb.0: // %entry
+; CHECK-NEXT:    ldr x0, t+4
+; CHECK-NEXT:    ret
+entry:
+  %0 = load i64, i64* getelementptr inbounds (%struct.T, %struct.T* @t, i64 0, i32 1), align 8
+  ret i64 %0
+}
+
+define i32 @bartc() {
+; CHECK-LABEL: bartc:
+; CHECK:       // %bb.0: // %entry
+; CHECK-NEXT:    adr x8, t+13
+; CHECK-NEXT:    ldr w0, [x8]
+; CHECK-NEXT:    ret
+entry:
+  %0 = load i32, i32* getelementptr inbounds (%struct.T, %struct.T* @t, i64 0, i32 3), align 1
+  ret i32 %0
+}
+
+define i32 @bart2a() {
+; CHECK-LABEL: bart2a:
+; CHECK:       // %bb.0: // %entry
+; CHECK-NEXT:    adr x8, t2
+; CHECK-NEXT:    ldr w0, [x8]
+; CHECK-NEXT:    ret
+entry:
+  %0 = load i32, i32* getelementptr inbounds (%struct.T, %struct.T* @t2, i64 0, i32 0), align 2
+  ret i32 %0
+}
+
+define i64 @zextload() {
+; CHECK-LABEL: zextload:
+; CHECK:       // %bb.0: // %entry
+; CHECK-NEXT:    ldr w0, ch
+; CHECK-NEXT:    ret
+entry:
+  %0 = load i32, i32* @ch, align 4
+  %1 = zext i32 %0 to i64
+  ret i64 %1
+}
+
+define i64 @sextload() {
+; CHECK-LABEL: sextload:
+; CHECK:       // %bb.0: // %entry
+; CHECK-NEXT:    ldrsw x0, ch
+; CHECK-NEXT:    ret
+entry:
+  %0 = load i32, i32* @ch, align 4
+  %1 = sext i32 %0 to i64
+  ret i64 %1
+}

test/CodeGen/AArch64/tiny_model.ll

 }
 
 define void @foo3() {
 ; FIXME: Needn't adr ptr
 ;
 ; CHECK-LABEL: foo3:
 ; CHECK:       // %bb.0: // %entry
 ; CHECK-NEXT:    adr x8, src
-; CHECK-NEXT:    adr x9, ptr
 ; CHECK-NEXT:    ldrb w8, [x8]
-; CHECK-NEXT:    ldr x9, [x9]
+; CHECK-NEXT:    ldr x9, ptr
 ; CHECK-NEXT:    strb w8, [x9]
 ; CHECK-NEXT:    ret
 ;
 ; CHECK-GLOBISEL-LABEL: foo3:
 ; CHECK-GLOBISEL:       // %bb.0: // %entry
 ; CHECK-GLOBISEL-NEXT:    adr x8, src
 ; CHECK-GLOBISEL-NEXT:    adr x9, ptr
 ; CHECK-GLOBISEL-NEXT:    ldrb w8, [x8]

 }
 
 define void @bar3() {
 ; FIXME: Needn't adr lptr
 ;
 ; CHECK-LABEL: bar3:
 ; CHECK:       // %bb.0: // %entry
 ; CHECK-NEXT:    adr x8, lsrc
-; CHECK-NEXT:    adr x9, lptr
 ; CHECK-NEXT:    ldrb w8, [x8]
-; CHECK-NEXT:    ldr x9, [x9]
+; CHECK-NEXT:    ldr x9, lptr
 ; CHECK-NEXT:    strb w8, [x9]
 ; CHECK-NEXT:    ret
 ;
 ; CHECK-GLOBISEL-LABEL: bar3:
 ; CHECK-GLOBISEL:       // %bb.0: // %entry
 ; CHECK-GLOBISEL-NEXT:    adr x8, lsrc
 ; CHECK-GLOBISEL-NEXT:    adr x9, lptr
 ; CHECK-GLOBISEL-NEXT:    ldrb w8, [x8]
 ; CHECK-GLOBISEL-NEXT:    ldr x9, [x9]
 ; CHECK-GLOBISEL-NEXT:    strb w8, [x9]
 ; CHECK-GLOBISEL-NEXT:    ret
 ;
 ; CHECK-PIC-LABEL: bar3:
 ; CHECK-PIC:       // %bb.0: // %entry
 ; CHECK-PIC-NEXT:    adr x8, lsrc
-; CHECK-PIC-NEXT:    adr x9, lptr
 ; CHECK-PIC-NEXT:    ldrb w8, [x8]
-; CHECK-PIC-NEXT:    ldr x9, [x9]
+; CHECK-PIC-NEXT:    ldr x9, lptr
 ; CHECK-PIC-NEXT:    strb w8, [x9]
 ; CHECK-PIC-NEXT:    ret
 ;
 ; CHECK-PIC-GLOBISEL-LABEL: bar3:
 ; CHECK-PIC-GLOBISEL:       // %bb.0: // %entry
 ; CHECK-PIC-GLOBISEL-NEXT:    adr x8, lsrc
 ; CHECK-PIC-GLOBISEL-NEXT:    adr x9, lptr
 ; CHECK-PIC-GLOBISEL-NEXT:    ldrb w8, [x8]

 }
 
 define void @baz3() {
 ; FIXME: Needn't adr lptr
 ;
 ; CHECK-LABEL: baz3:
 ; CHECK:       // %bb.0: // %entry
 ; CHECK-NEXT:    adr x8, lbsrc
-; CHECK-NEXT:    adr x9, lptr
 ; CHECK-NEXT:    ldrb w8, [x8]
-; CHECK-NEXT:    ldr x9, [x9]
+; CHECK-NEXT:    ldr x9, lptr
 ; CHECK-NEXT:    strb w8, [x9]
 ; CHECK-NEXT:    ret
 ;
 ; CHECK-GLOBISEL-LABEL: baz3:
 ; CHECK-GLOBISEL:       // %bb.0: // %entry
 ; CHECK-GLOBISEL-NEXT:    adr x8, lbsrc
 ; CHECK-GLOBISEL-NEXT:    adr x9, lptr
 ; CHECK-GLOBISEL-NEXT:    ldrb w8, [x8]
 ; CHECK-GLOBISEL-NEXT:    ldr x9, [x9]
 ; CHECK-GLOBISEL-NEXT:    strb w8, [x9]
 ; CHECK-GLOBISEL-NEXT:    ret
 ;
 ; CHECK-PIC-LABEL: baz3:
 ; CHECK-PIC:       // %bb.0: // %entry
 ; CHECK-PIC-NEXT:    adr x8, lbsrc
-; CHECK-PIC-NEXT:    adr x9, lptr
 ; CHECK-PIC-NEXT:    ldrb w8, [x8]
-; CHECK-PIC-NEXT:    ldr x9, [x9]
+; CHECK-PIC-NEXT:    ldr x9, lptr
 ; CHECK-PIC-NEXT:    strb w8, [x9]
 ; CHECK-PIC-NEXT:    ret
 ;
 ; CHECK-PIC-GLOBISEL-LABEL: baz3:
 ; CHECK-PIC-GLOBISEL:       // %bb.0: // %entry
 ; CHECK-PIC-GLOBISEL-NEXT:    adr x8, lbsrc
 ; CHECK-PIC-GLOBISEL-NEXT:    adr x9, lptr
 ; CHECK-PIC-GLOBISEL-NEXT:    ldrb w8, [x8]