llvm-6502/test/CodeGen/X86/tls-pie.ll

74 lines
1.7 KiB
LLVM
Raw Normal View History

; RUN: llc < %s -march=x86 -mcpu=generic -mtriple=i386-linux-gnu -relocation-model=pic -enable-pie \
; RUN: | FileCheck -check-prefix=X32 %s
; RUN: llc < %s -march=x86-64 -mcpu=generic -mtriple=x86_64-linux-gnu -relocation-model=pic -enable-pie \
; RUN: | FileCheck -check-prefix=X64 %s
@i = thread_local global i32 15
@i2 = external thread_local global i32
define i32 @f1() {
; X32-LABEL: f1:
; X32: movl %gs:i@NTPOFF, %eax
; X32-NEXT: ret
; X64-LABEL: f1:
Cleanup and relax a restriction on the matching of global offsets into x86 addressing modes. This allows PIE-based TLS offsets to fit directly into an addressing mode immediate offset, which is the last remaining code quality issue from PR12380. With this patch, that PR is completely fixed. To understand why this patch is correct to match these offsets into addressing mode immediates, break it down by cases: 1) 32-bit is trivially correct, and unmodified here. 2) 64-bit non-small mode is unchanged and never matches. 3) 64-bit small PIC code which is RIP-relative is handled specially in the match to try to fit RIP into the base register. If it fails, it now early exits. This behavior is unchanged by the patch. 4) 64-bit small non-PIC code which is not RIP-relative continues to work as it did before. The reason these immediates are safe is because the ABI ensures they fit in small mode. This behavior is unchanged. 5) 64-bit small PIC code which is *not* using RIP-relative addressing. This is the only case changed by the patch, and the primary place you see it is in TLS, either the win64 section offset TLS or Linux local-exec TLS model in a PIC compilation. Here the ABI again ensures that the immediates fit because we are in small mode, and any other operations required due to the PIC relocation model have been handled externally to the Wrapper node (extra loads etc are made around the wrapper node in ISelLowering). I've tested this as much as I can comparing it with GCC's output, and everything appears safe. I discussed this with Anton and it made sense to him at least at face value. That said, if there are issues with PIC code after this patch, yell and we can revert it. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154304 91177308-0d34-0410-b5e6-96231b3b80d8
2012-04-09 02:13:06 +00:00
; X64: movl %fs:i@TPOFF, %eax
; X64-NEXT: ret
entry:
%tmp1 = load i32* @i
ret i32 %tmp1
}
define i32* @f2() {
; X32-LABEL: f2:
; X32: movl %gs:0, %eax
; X32-NEXT: leal i@NTPOFF(%eax), %eax
; X32-NEXT: ret
; X64-LABEL: f2:
; X64: movq %fs:0, %rax
Cleanup and relax a restriction on the matching of global offsets into x86 addressing modes. This allows PIE-based TLS offsets to fit directly into an addressing mode immediate offset, which is the last remaining code quality issue from PR12380. With this patch, that PR is completely fixed. To understand why this patch is correct to match these offsets into addressing mode immediates, break it down by cases: 1) 32-bit is trivially correct, and unmodified here. 2) 64-bit non-small mode is unchanged and never matches. 3) 64-bit small PIC code which is RIP-relative is handled specially in the match to try to fit RIP into the base register. If it fails, it now early exits. This behavior is unchanged by the patch. 4) 64-bit small non-PIC code which is not RIP-relative continues to work as it did before. The reason these immediates are safe is because the ABI ensures they fit in small mode. This behavior is unchanged. 5) 64-bit small PIC code which is *not* using RIP-relative addressing. This is the only case changed by the patch, and the primary place you see it is in TLS, either the win64 section offset TLS or Linux local-exec TLS model in a PIC compilation. Here the ABI again ensures that the immediates fit because we are in small mode, and any other operations required due to the PIC relocation model have been handled externally to the Wrapper node (extra loads etc are made around the wrapper node in ISelLowering). I've tested this as much as I can comparing it with GCC's output, and everything appears safe. I discussed this with Anton and it made sense to him at least at face value. That said, if there are issues with PIC code after this patch, yell and we can revert it. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154304 91177308-0d34-0410-b5e6-96231b3b80d8
2012-04-09 02:13:06 +00:00
; X64-NEXT: leaq i@TPOFF(%rax), %rax
; X64-NEXT: ret
entry:
ret i32* @i
}
define i32 @f3() {
; X32-LABEL: f3:
; X32: calll .L{{[0-9]+}}$pb
; X32-NEXT: .L{{[0-9]+}}$pb:
; X32-NEXT: popl %eax
; X32-NEXT: .Ltmp{{[0-9]+}}:
; X32-NEXT: addl $_GLOBAL_OFFSET_TABLE_+(.Ltmp{{[0-9]+}}-.L{{[0-9]+}}$pb), %eax
; X32-NEXT: movl i2@GOTNTPOFF(%eax), %eax
; X32-NEXT: movl %gs:(%eax), %eax
; X32-NEXT: ret
; X64-LABEL: f3:
; X64: movq i2@GOTTPOFF(%rip), %rax
; X64-NEXT: movl %fs:(%rax), %eax
; X64-NEXT: ret
entry:
%tmp1 = load i32* @i2
ret i32 %tmp1
}
define i32* @f4() {
; X32-LABEL: f4:
; X32: calll .L{{[0-9]+}}$pb
; X32-NEXT: .L{{[0-9]+}}$pb:
; X32-NEXT: popl %ecx
; X32-NEXT: .Ltmp{{[0-9]+}}:
; X32-NEXT: addl $_GLOBAL_OFFSET_TABLE_+(.Ltmp{{[0-9]+}}-.L{{[0-9]+}}$pb), %ecx
; X32-NEXT: movl %gs:0, %eax
; X32-NEXT: addl i2@GOTNTPOFF(%ecx), %eax
; X32-NEXT: ret
; X64-LABEL: f4:
; X64: movq %fs:0, %rax
; X64-NEXT: addq i2@GOTTPOFF(%rip), %rax
; X64-NEXT: ret
entry:
ret i32* @i2
}