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/AArch64/global-merge-ignore-single-...

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

65 lines
1.7 KiB
LLVM
Raw Normal View History

[AArch64] Register passes so they can be run by llc Initialize all AArch64-specific passes in the TargetMachine so they can be run by llc. This can lead to conflicts in opt with some command line options that share the same name as the pass, so I took this opportunity to do some cleanups: * rename all relevant command line options from "aarch64-blah" to "aarch64-enable-blah" and update the tests accordingly * run clang-format on their declarations * move all these declarations to a common place (the TargetMachine) as opposed to having them scattered around (AArch64BranchRelaxation and AArch64AddressTypePromotion were the only offenders) llvm-svn: 277322
2016-08-01 13:56:57 +08:00
; RUN: llc -mtriple=aarch64-apple-ios -asm-verbose=false \
; RUN: -aarch64-enable-collect-loh=false -aarch64-enable-global-merge \
; RUN: -global-merge-group-by-use -global-merge-ignore-single-use %s -o - \
; RUN: | FileCheck %s
[GlobalMerge] Look at uses to create smaller global sets. Instead of merging everything together, look at the users of GlobalVariables, and try to group them by function, to create sets of globals used "together". Using that information, a less-aggressive alternative is to keep merging everything together *except* globals that are only ever used alone, that is, those for which it's clearly non-profitable to merge with others. In my testing, grouping by Function is too aggressive, but grouping by BasicBlock is too conservative. Anything in-between isn't trivially available, so stick with Function grouping for now. cl::opts are added for testing; both enabled by default. A few of the testcases aren't testing the merging proper, but just various edge cases when merging does occur. Update them to use the previous grouping behavior. Also, one of the tests is unrelated to GlobalMerge; change it accordingly. While there, switch to r234666' flags rather than the brutal -O3. Differential Revision: http://reviews.llvm.org/D8070 llvm-svn: 235249
2015-04-18 09:21:58 +08:00
; We assume that globals of the same size aren't reordered inside a set.
@m1 = internal global i32 0, align 4
@n1 = internal global i32 0, align 4
@o1 = internal global i32 0, align 4
; CHECK-LABEL: f1:
define void @f1(i32 %a1, i32 %a2) #0 {
Revert "Use private linkage for MergedGlobals variables" on Darwin. This is a partial revert of r244615 (http://reviews.llvm.org/D11942), which caused a major regression in debug info quality. Turning the artificial __MergedGlobal symbols into private symbols (l__MergedGlobal) means that the linker will not include them in the symbol table of the final executable. Without a symbol table entry dsymutil is not be able to process the debug info for any of the merged globals and thus drops the debug info for all of them. This patch is enabling the old behavior for all MachO targets while leaving all other targets unaffected. rdar://problem/29160481 https://reviews.llvm.org/D26531 llvm-svn: 286607
2016-11-12 01:50:09 +08:00
; CHECK-NEXT: adrp x8, [[SET:__MergedGlobals]]@PAGE
[GlobalMerge] Look at uses to create smaller global sets. Instead of merging everything together, look at the users of GlobalVariables, and try to group them by function, to create sets of globals used "together". Using that information, a less-aggressive alternative is to keep merging everything together *except* globals that are only ever used alone, that is, those for which it's clearly non-profitable to merge with others. In my testing, grouping by Function is too aggressive, but grouping by BasicBlock is too conservative. Anything in-between isn't trivially available, so stick with Function grouping for now. cl::opts are added for testing; both enabled by default. A few of the testcases aren't testing the merging proper, but just various edge cases when merging does occur. Update them to use the previous grouping behavior. Also, one of the tests is unrelated to GlobalMerge; change it accordingly. While there, switch to r234666' flags rather than the brutal -O3. Differential Revision: http://reviews.llvm.org/D8070 llvm-svn: 235249
2015-04-18 09:21:58 +08:00
; CHECK-NEXT: add x8, x8, [[SET]]@PAGEOFF
; CHECK-NEXT: stp w0, w1, [x8]
; CHECK-NEXT: ret
store i32 %a1, i32* @m1, align 4
store i32 %a2, i32* @n1, align 4
ret void
}
@m2 = internal global i32 0, align 4
@n2 = internal global i32 0, align 4
; CHECK-LABEL: f2:
define void @f2(i32 %a1, i32 %a2, i32 %a3) #0 {
; CHECK-NEXT: adrp x8, [[SET]]@PAGE
; CHECK-NEXT: add x8, x8, [[SET]]@PAGEOFF
; CHECK-NEXT: stp w0, w1, [x8]
; CHECK-NEXT: str w2, [x8, #8]
; CHECK-NEXT: ret
store i32 %a1, i32* @m1, align 4
store i32 %a2, i32* @n1, align 4
store i32 %a3, i32* @o1, align 4
ret void
}
; CHECK-LABEL: f3:
define void @f3(i32 %a1, i32 %a2) #0 {
Reland r329956, "AArch64: Introduce a DAG combine for folding offsets into addresses.", with a fix for the bot failure. This reland includes a check to prevent the DAG combiner from folding an offset that is smaller than the existing one. This can cause oscillations between two possible DAGs, which was the cause of the hang and later assertion failure observed on the lnt-ctmark-aarch64-O3-flto bot. http://green.lab.llvm.org/green/job/lnt-ctmark-aarch64-O3-flto/2024/ Original commit message: > This is a code size win in code that takes offseted addresses > frequently, such as C++ constructors that typically need to compute > an offseted address of a vtable. This reduces the size of Chromium > for Android's .text section by 108KB. Differential Revision: https://reviews.llvm.org/D45199 llvm-svn: 330630
2018-04-24 03:09:34 +08:00
; CHECK-NEXT: adrp x8, [[SET]]@PAGE+12
; CHECK-NEXT: add x8, x8, [[SET]]@PAGEOFF+12
; CHECK-NEXT: stp w0, w1, [x8]
[GlobalMerge] Look at uses to create smaller global sets. Instead of merging everything together, look at the users of GlobalVariables, and try to group them by function, to create sets of globals used "together". Using that information, a less-aggressive alternative is to keep merging everything together *except* globals that are only ever used alone, that is, those for which it's clearly non-profitable to merge with others. In my testing, grouping by Function is too aggressive, but grouping by BasicBlock is too conservative. Anything in-between isn't trivially available, so stick with Function grouping for now. cl::opts are added for testing; both enabled by default. A few of the testcases aren't testing the merging proper, but just various edge cases when merging does occur. Update them to use the previous grouping behavior. Also, one of the tests is unrelated to GlobalMerge; change it accordingly. While there, switch to r234666' flags rather than the brutal -O3. Differential Revision: http://reviews.llvm.org/D8070 llvm-svn: 235249
2015-04-18 09:21:58 +08:00
; CHECK-NEXT: ret
store i32 %a1, i32* @m2, align 4
store i32 %a2, i32* @n2, align 4
ret void
}
@o2 = internal global i32 0, align 4
; CHECK-LABEL: f4:
define void @f4(i32 %a1) #0 {
; CHECK-NEXT: adrp x8, _o2@PAGE
; CHECK-NEXT: str w0, [x8, _o2@PAGEOFF]
; CHECK-NEXT: ret
store i32 %a1, i32* @o2, align 4
ret void
}
[GlobalMerge] Set the alignment on merged global structs If no alignment is set, the abi/preferred alignment of structs will be used which may be higher than required. This can lead to extra padding and in the end an increase in data size. Differential Revision: https://reviews.llvm.org/D47633 llvm-svn: 334099
2018-06-06 22:48:32 +08:00
; CHECK-DAG: .zerofill __DATA,__bss,[[SET]],20,2
[GlobalMerge] Look at uses to create smaller global sets. Instead of merging everything together, look at the users of GlobalVariables, and try to group them by function, to create sets of globals used "together". Using that information, a less-aggressive alternative is to keep merging everything together *except* globals that are only ever used alone, that is, those for which it's clearly non-profitable to merge with others. In my testing, grouping by Function is too aggressive, but grouping by BasicBlock is too conservative. Anything in-between isn't trivially available, so stick with Function grouping for now. cl::opts are added for testing; both enabled by default. A few of the testcases aren't testing the merging proper, but just various edge cases when merging does occur. Update them to use the previous grouping behavior. Also, one of the tests is unrelated to GlobalMerge; change it accordingly. While there, switch to r234666' flags rather than the brutal -O3. Differential Revision: http://reviews.llvm.org/D8070 llvm-svn: 235249
2015-04-18 09:21:58 +08:00
; CHECK-DAG: .zerofill __DATA,__bss,_o2,4,2
attributes #0 = { nounwind }