RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-10-30 23:42:52 +01:00
Code Issues Projects Releases Wiki Activity
84c6cd222d
llvm-mirror/test/CodeGen/PowerPC/tls-ld-obj.ll

35 lines
1.2 KiB
LLVM
Raw Normal View History

This patch implements local-dynamic TLS model support for the 64-bit PowerPC target. This is the last of the four models, so we now have full TLS support. This is mostly a straightforward extension of the general dynamic model. I had to use an additional Chain operand to tie ADDIS_DTPREL_HA to the register copy following ADDI_TLSLD_L; otherwise everything above the ADDIS_DTPREL_HA appeared dead and was removed. As before, there are new test cases to test the assembly generation, and the relocations output during integrated assembly. The expected code gen sequence can be read in test/CodeGen/PowerPC/tls-ld.ll. There are a couple of things I think can be done more efficiently in the overall TLS code, so there will likely be a clean-up patch forthcoming; but for now I want to be sure the functionality is in place. Bill llvm-svn: 170003
2012-12-12 20:29:35 +01:00
; RUN: llc -mcpu=pwr7 -O0 -filetype=obj -relocation-model=pic %s -o - | \
Replace coff-/elf-dump with llvm-readobj llvm-svn: 179361
2013-04-12 06:06:46 +02:00
; RUN: llvm-readobj -r | FileCheck %s
This patch implements local-dynamic TLS model support for the 64-bit PowerPC target. This is the last of the four models, so we now have full TLS support. This is mostly a straightforward extension of the general dynamic model. I had to use an additional Chain operand to tie ADDIS_DTPREL_HA to the register copy following ADDI_TLSLD_L; otherwise everything above the ADDIS_DTPREL_HA appeared dead and was removed. As before, there are new test cases to test the assembly generation, and the relocations output during integrated assembly. The expected code gen sequence can be read in test/CodeGen/PowerPC/tls-ld.ll. There are a couple of things I think can be done more efficiently in the overall TLS code, so there will likely be a clean-up patch forthcoming; but for now I want to be sure the functionality is in place. Bill llvm-svn: 170003
2012-12-12 20:29:35 +01:00
; Test correct relocation generation for thread-local storage using
; the local dynamic model.
target datalayout = "E-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-f128:128:128-v128:128:128-n32:64"
target triple = "powerpc64-unknown-linux-gnu"
@a = hidden thread_local global i32 0, align 4
define signext i32 @main() nounwind {
entry:
%retval = alloca i32, align 4
store i32 0, i32* %retval
%0 = load i32* @a, align 4
ret i32 %0
}
The ordering of two relocations on the same instruction is apparently not predictable when compiled on at least one non-PowerPC host. Source of nondeterminism not apparent. Restrict the test to build on PowerPC hosts for now while looking into the issue further. llvm-svn: 170016
2012-12-12 21:29:20 +01:00
; Verify generation of R_PPC64_GOT_TLSLD16_HA, R_PPC64_GOT_TLSLD16_LO,
; R_PPC64_TLSLD, R_PPC64_DTPREL16_HA, and R_PPC64_DTPREL16_LO for
; accessing external variable a, and R_PPC64_REL24 for the call to
; __tls_get_addr.
This patch implements local-dynamic TLS model support for the 64-bit PowerPC target. This is the last of the four models, so we now have full TLS support. This is mostly a straightforward extension of the general dynamic model. I had to use an additional Chain operand to tie ADDIS_DTPREL_HA to the register copy following ADDI_TLSLD_L; otherwise everything above the ADDIS_DTPREL_HA appeared dead and was removed. As before, there are new test cases to test the assembly generation, and the relocations output during integrated assembly. The expected code gen sequence can be read in test/CodeGen/PowerPC/tls-ld.ll. There are a couple of things I think can be done more efficiently in the overall TLS code, so there will likely be a clean-up patch forthcoming; but for now I want to be sure the functionality is in place. Bill llvm-svn: 170003
2012-12-12 20:29:35 +01:00
;
Replace coff-/elf-dump with llvm-readobj llvm-svn: 179361
2013-04-12 06:06:46 +02:00
; CHECK: Relocations [
Change how we iterate over relocations on ELF. For COFF and MachO, sections semantically have relocations that apply to them. That is not the case on ELF. In relocatable objects (.o), a section with relocations in ELF has offsets to another section where the relocations should be applied. In dynamic objects and executables, relocations don't have an offset, they have a virtual address. The section sh_info may or may not point to another section, but that is not actually used for resolving the relocations. This patch exposes that in the ObjectFile API. It has the following advantages: * Most (all?) clients can handle this more efficiently. They will normally walk all relocations, so doing an effort to iterate in a particular order doesn't save time. * llvm-readobj now prints relocations in the same way the native readelf does. * probably most important, relocations that don't point to any section are now visible. This is the case of relocations in the rela.dyn section. See the updated relocation-executable.test for example. llvm-svn: 182908
2013-05-30 05:05:14 +02:00
; CHECK: Section (2) .rela.text {
Replace coff-/elf-dump with llvm-readobj llvm-svn: 179361
2013-04-12 06:06:46 +02:00
; CHECK: 0x{{[0-9,A-F]+}} R_PPC64_GOT_TLSLD16_HA a
; CHECK: 0x{{[0-9,A-F]+}} R_PPC64_GOT_TLSLD16_LO a
; CHECK: 0x{{[0-9,A-F]+}} R_PPC64_TLSLD a
; CHECK: 0x{{[0-9,A-F]+}} R_PPC64_REL24 __tls_get_addr
; CHECK: 0x{{[0-9,A-F]+}} R_PPC64_DTPREL16_HA a
; CHECK: 0x{{[0-9,A-F]+}} R_PPC64_DTPREL16_LO a
; CHECK: }
; CHECK: ]
Reference in New Issue Copy Permalink