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-group-by-use.ll

95 lines
2.7 KiB
LLVM
Raw Normal View History

[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
; RUN: llc -mtriple=aarch64-apple-ios -asm-verbose=false -aarch64-collect-loh=false \
; RUN: -aarch64-global-merge -global-merge-group-by-use -global-merge-ignore-single-use=false \
; RUN: %s -o - | FileCheck %s
; We assume that globals of the same size aren't reordered inside a set.
; Check that we create two MergedGlobal instances for two functions using
; disjoint sets of globals
@m1 = internal global i32 0, align 4
@n1 = internal global i32 0, align 4
; CHECK-LABEL: f1:
define void @f1(i32 %a1, i32 %a2) #0 {
[GlobalMerge] Use private linkage for MergedGlobals variables Other objects can never reference the MergedGlobals symbol so external linkage is never needed. Using private instead of internal linkage means the object is more similar to what it looks like when global merging is not enabled, with the only difference being that the merged variables are addressed indirectly relative to the start of the section they are in. Also add aliases for merged variables with internal linkage, as this also makes the object be more like what it is when they are not merged. Differential Revision: http://reviews.llvm.org/D11942 llvm-svn: 244615
2015-08-11 23:48:04 +08:00
; CHECK-NEXT: adrp x8, [[SET1:l__MergedGlobals.[0-9]*]]@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, [[SET1]]@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
@o2 = internal global i32 0, align 4
; CHECK-LABEL: f2:
define void @f2(i32 %a1, i32 %a2, i32 %a3) #0 {
[GlobalMerge] Use private linkage for MergedGlobals variables Other objects can never reference the MergedGlobals symbol so external linkage is never needed. Using private instead of internal linkage means the object is more similar to what it looks like when global merging is not enabled, with the only difference being that the merged variables are addressed indirectly relative to the start of the section they are in. Also add aliases for merged variables with internal linkage, as this also makes the object be more like what it is when they are not merged. Differential Revision: http://reviews.llvm.org/D11942 llvm-svn: 244615
2015-08-11 23:48:04 +08:00
; CHECK-NEXT: adrp x8, [[SET2:l__MergedGlobals.[0-9]*]]@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, [[SET2]]@PAGEOFF
; CHECK-NEXT: stp w0, w1, [x8]
; CHECK-NEXT: str w2, [x8, #8]
; CHECK-NEXT: ret
store i32 %a1, i32* @m2, align 4
store i32 %a2, i32* @n2, align 4
store i32 %a3, i32* @o2, align 4
ret void
}
; Sanity-check (don't worry about cost models) that we pick the biggest subset
; of all global used "together" directly or indirectly. Here, that means
; merging n3, m4, and n4 together, but ignoring m3.
@m3 = internal global i32 0, align 4
@n3 = internal global i32 0, align 4
; CHECK-LABEL: f3:
define void @f3(i32 %a1, i32 %a2) #0 {
; CHECK-NEXT: adrp x8, _m3@PAGE
[GlobalMerge] Use private linkage for MergedGlobals variables Other objects can never reference the MergedGlobals symbol so external linkage is never needed. Using private instead of internal linkage means the object is more similar to what it looks like when global merging is not enabled, with the only difference being that the merged variables are addressed indirectly relative to the start of the section they are in. Also add aliases for merged variables with internal linkage, as this also makes the object be more like what it is when they are not merged. Differential Revision: http://reviews.llvm.org/D11942 llvm-svn: 244615
2015-08-11 23:48:04 +08:00
; CHECK-NEXT: adrp x9, [[SET3:l__MergedGlobals[0-9]*]]@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: str w0, [x8, _m3@PAGEOFF]
; CHECK-NEXT: str w1, [x9, [[SET3]]@PAGEOFF]
; CHECK-NEXT: ret
store i32 %a1, i32* @m3, align 4
store i32 %a2, i32* @n3, align 4
ret void
}
@m4 = internal global i32 0, align 4
@n4 = internal global i32 0, align 4
; CHECK-LABEL: f4:
define void @f4(i32 %a1, i32 %a2, i32 %a3) #0 {
; CHECK-NEXT: adrp x8, [[SET3]]@PAGE
; CHECK-NEXT: add x8, x8, [[SET3]]@PAGEOFF
[MachineScheduler]Add support for store clustering Perform store clustering just like load clustering. This change add StoreClusterMutation in machine-scheduler. To control StoreClusterMutation, added enableClusterStores() in TargetInstrInfo.h. This is enabled only on AArch64 for now. This change also add support for unscaled stores which were not handled in getMemOpBaseRegImmOfs(). llvm-svn: 266437
2016-04-15 22:58:38 +08:00
; CHECK-NEXT: stp w2, w0, [x8]
; CHECK-NEXT: str w1, [x8, #8]
[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* @m4, align 4
store i32 %a2, i32* @n4, align 4
store i32 %a3, i32* @n3, align 4
ret void
}
; Finally, check that we don't do anything with one-element global sets.
@o5 = internal global i32 0, align 4
; CHECK-LABEL: f5:
define void @f5(i32 %a1) #0 {
; CHECK-NEXT: adrp x8, _o5@PAGE
; CHECK-NEXT: str w0, [x8, _o5@PAGEOFF]
; CHECK-NEXT: ret
store i32 %a1, i32* @o5, align 4
ret void
}
; CHECK-DAG: .zerofill __DATA,__bss,_o5,4,2
; CHECK-DAG: .zerofill __DATA,__bss,[[SET1]],8,3
; CHECK-DAG: .zerofill __DATA,__bss,[[SET2]],12,3
; CHECK-DAG: .zerofill __DATA,__bss,[[SET3]],12,3
attributes #0 = { nounwind }