mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-10-23 13:02:52 +02:00
5f7a3665f1
Given something like:
ldr r0, .LCPI0_0 (== pc-rel var)
add r0, pc
ldr r1, .LCPI0_1 (== pc-rel var)
add r1, pc
we cannot combine the 2 ldr instructions and litpools because they get added to
a different pc to form the correct address. I think the original logic came
from a time when we fused the LDRpci/PICADD instructions into one
pseudo-instruction so the PC was always immediately at-hand. That's no longer
the case.
Should fix general-dynamic TLS access on Linux, and quite possibly other -fPIC
code that relies on litpools (e.g. v6m and -Oz compilations) though trivial
tweaks of the .ll test didn't provoke anything.
llvm-svn: 268662
46 lines
1.0 KiB
LLVM
46 lines
1.0 KiB
LLVM
; RUN: llc -mtriple=thumbv7-linux-gnueabihf -relocation-model=pic %s -o - | FileCheck %s
|
|
|
|
@var = thread_local global i32 0, align 4
|
|
|
|
define void @func(i32 %n) {
|
|
; CHECK-LABEL: func:
|
|
; CHECK: ldr [[REF1:r[0-9]+]], [[CP1:.LCPI[0-9]+_[0-9]+]]
|
|
; CHECK: ldr [[REF2:r[0-9]+]], [[CP2:.LCPI[0-9]+_[0-9]+]]
|
|
|
|
; CHECK: [[PCPOS1:.LPC[0-9]+_[0-9]+]]:
|
|
; CHECK-NEXT: add [[REF1]], pc
|
|
|
|
; CHECK: [[PCPOS2:.LPC[0-9]+_[0-9]+]]:
|
|
; CHECK-NEXT: add [[REF2]], pc
|
|
|
|
; CHECK: [[CP1]]:
|
|
; CHECK-NEXT: [[CP1_TMP:.Ltmp[0-9]+]]:
|
|
; CHECK-NEXT: .long var(TLSGD)-(([[PCPOS1]]+4)-[[CP1_TMP]])
|
|
|
|
; CHECK: [[CP2]]:
|
|
; CHECK-NEXT: [[CP2_TMP:.Ltmp[0-9]+]]:
|
|
; CHECK-NEXT: .long var(TLSGD)-(([[PCPOS2]]+4)-[[CP2_TMP]])
|
|
|
|
entry:
|
|
br label %loop
|
|
|
|
loop:
|
|
%i = phi i32 [ %inc, %next ], [ 0, %entry ]
|
|
%val = load i32, i32* @var
|
|
%tst = icmp eq i32 %val, 0
|
|
br i1 %tst, label %next, label %call
|
|
|
|
call:
|
|
tail call void @foo(i32* nonnull @var) #2
|
|
br label %next
|
|
|
|
next:
|
|
%inc = add i32 %i, 1
|
|
%stop = icmp eq i32 %inc, %n
|
|
br i1 %stop, label %done, label %loop
|
|
|
|
done:
|
|
ret void
|
|
}
|
|
|
|
declare void @foo(i32*) |