maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/CodeGen/Mips/emutls_generic.ll

71 lines
2.1 KiB
LLVM
Raw Normal View History

Move unit tests to target specific directories. Differential Revision: http://reviews.llvm.org/D10522 llvm-svn: 243454
2015-07-29 01:32:49 +08:00
; RUN: llc < %s -emulated-tls -mtriple=mipsel-linux-android -relocation-model=pic \
; RUN: | FileCheck -check-prefix=MIPS_32 %s
; RUN: llc < %s -emulated-tls -mtriple=mips64el-linux-android -relocation-model=pic \
; RUN: | FileCheck -check-prefix=MIPS_64 %s
; Make sure that TLS symbols are emitted in expected order.
@external_x = external thread_local global i32, align 8
@external_y = thread_local global i8 7, align 2
@internal_y = internal thread_local global i64 9, align 16
define i32* @get_external_x() {
entry:
ret i32* @external_x
}
define i8* @get_external_y() {
entry:
ret i8* @external_y
}
define i64* @get_internal_y() {
entry:
ret i64* @internal_y
}
; MIPS_32-LABEL: get_external_y:
; MIPS_32-LABEL: get_internal_y:
; MIPS_32: lw {{.+}}(__emutls_v.internal_y
; MIPS_32: lw {{.+}}call16(__emutls_get_address
; MIPS_32-NOT: __emutls_t.external_x
; MIPS_32-NOT: __emutls_v.external_x:
Stop producing .data.rel sections. If a section is rw, it is irrelevant if the dynamic linker will write to it or not. It looks like llvm implemented this because gcc was doing it. It looks like gcc implemented this in the hope that it would put all the relocated items close together and speed up the dynamic linker. There are two problem with this: * It doesn't work. Both bfd and gold will map .data.rel to .data and concatenate the input sections in the order they are seen. * If we want a feature like that, it can be implemented directly in the linker since it knowns where the dynamic relocations are. llvm-svn: 253436
2015-11-18 14:02:15 +08:00
; MIPS_32: .data
[MC] Use .p2align instead of .align For historic reasons, the behavior of .align differs between targets. Fortunately, there are alternatives, .p2align and .balign, which make the interpretation of the parameter explicit, and which behave consistently across targets. This patch teaches MC to use .p2align instead of .align, so that people reading code for multiple architectures don't have to remember which way each platform does its .align directive. Differential Revision: http://reviews.llvm.org/D16549 llvm-svn: 258750
2016-01-26 08:03:25 +08:00
; MIPS_32: .p2align 2
Move unit tests to target specific directories. Differential Revision: http://reviews.llvm.org/D10522 llvm-svn: 243454
2015-07-29 01:32:49 +08:00
; MIPS_32-LABEL: __emutls_v.external_y:
; MIPS_32: .section .rodata,
; MIPS_32-LABEL: __emutls_t.external_y:
; MIPS_32-NEXT: .byte 7
Stop producing .data.rel sections. If a section is rw, it is irrelevant if the dynamic linker will write to it or not. It looks like llvm implemented this because gcc was doing it. It looks like gcc implemented this in the hope that it would put all the relocated items close together and speed up the dynamic linker. There are two problem with this: * It doesn't work. Both bfd and gold will map .data.rel to .data and concatenate the input sections in the order they are seen. * If we want a feature like that, it can be implemented directly in the linker since it knowns where the dynamic relocations are. llvm-svn: 253436
2015-11-18 14:02:15 +08:00
; MIPS_32: .data
[MC] Use .p2align instead of .align For historic reasons, the behavior of .align differs between targets. Fortunately, there are alternatives, .p2align and .balign, which make the interpretation of the parameter explicit, and which behave consistently across targets. This patch teaches MC to use .p2align instead of .align, so that people reading code for multiple architectures don't have to remember which way each platform does its .align directive. Differential Revision: http://reviews.llvm.org/D16549 llvm-svn: 258750
2016-01-26 08:03:25 +08:00
; MIPS_32: .p2align 2
Move unit tests to target specific directories. Differential Revision: http://reviews.llvm.org/D10522 llvm-svn: 243454
2015-07-29 01:32:49 +08:00
; MIPS_32-LABEL: __emutls_v.internal_y:
; MIPS_32-NEXT: .4byte 8
; MIPS_32-NEXT: .4byte 16
; MIPS_32-NEXT: .4byte 0
; MIPS_32-NEXT: .4byte __emutls_t.internal_y
; MIPS_32-LABEL: __emutls_t.internal_y:
; MIPS_32-NEXT: .8byte 9
; MIPS_64-LABEL: get_external_x:
; MIPS_64-LABEL: get_external_y:
; MIPS_64-LABEL: get_internal_y:
; MIPS_64: ld {{.+}}(__emutls_v.internal_y
; MIPS_64: ld {{.+}}call16(__emutls_get_address
; MIPS_64-NOT: __emutls_t.external_x
; MIPS_64-NOT: __emutls_v.external_x:
; MIPS_64-LABEL: __emutls_v.external_y:
; MIPS_64-NOT: __emutls_v.external_x:
; MIPS_64: .section .rodata,
; MIPS_64-LABEL: __emutls_t.external_y:
; MIPS_64-NEXT: .byte 7
Stop producing .data.rel sections. If a section is rw, it is irrelevant if the dynamic linker will write to it or not. It looks like llvm implemented this because gcc was doing it. It looks like gcc implemented this in the hope that it would put all the relocated items close together and speed up the dynamic linker. There are two problem with this: * It doesn't work. Both bfd and gold will map .data.rel to .data and concatenate the input sections in the order they are seen. * If we want a feature like that, it can be implemented directly in the linker since it knowns where the dynamic relocations are. llvm-svn: 253436
2015-11-18 14:02:15 +08:00
; MIPS_64: .data
[MC] Use .p2align instead of .align For historic reasons, the behavior of .align differs between targets. Fortunately, there are alternatives, .p2align and .balign, which make the interpretation of the parameter explicit, and which behave consistently across targets. This patch teaches MC to use .p2align instead of .align, so that people reading code for multiple architectures don't have to remember which way each platform does its .align directive. Differential Revision: http://reviews.llvm.org/D16549 llvm-svn: 258750
2016-01-26 08:03:25 +08:00
; MIPS_64: .p2align 3
Move unit tests to target specific directories. Differential Revision: http://reviews.llvm.org/D10522 llvm-svn: 243454
2015-07-29 01:32:49 +08:00
; MIPS_64-LABEL: __emutls_v.internal_y:
; MIPS_64-NEXT: .8byte 8
; MIPS_64-NEXT: .8byte 16
; MIPS_64-NEXT: .8byte 0
; MIPS_64-NEXT: .8byte __emutls_t.internal_y
; MIPS_64: .section .rodata,
; MIPS_64-LABEL: __emutls_t.internal_y:
; MIPS_64-NEXT: .8byte 9