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/ARM/global-merge.ll

75 lines
3.0 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 < %s -mtriple=thumb-apple-darwin -arm-global-merge -global-merge-group-by-use=false -global-merge-on-const=true | FileCheck %s
ARM: Do not use llc -march in tests. `llc -march` is problematic because it only switches the target architecture, but leaves the operating system unchanged. This occasionally leads to indeterministic tests because the OS from LLVM_DEFAULT_TARGET_TRIPLE is used. However we can simply always use `llc -mtriple` instead. This changes all the tests to do this to avoid people using -march when they copy and paste parts of tests. See also the discussion in https://reviews.llvm.org/D35287 llvm-svn: 309755
2017-08-02 06:20:49 +08:00
; Test the ARMGlobalMerge pass. Use -mtriple=thumb because it has a small
Fix the ARMGlobalMerge pass to look at variable sizes instead of pointer sizes. It was mistakenly looking at the pointer type when checking for the size of global variables. This is a partial fix for Radar 8673120. llvm-svn: 119563
2010-11-18 05:25:27 +08:00
; value for the maximum offset (127).
; A local array that exceeds the maximum offset should not be merged.
; CHECK: g0:
@g0 = internal global [32 x i32] [ i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7, i32 8, i32 9, i32 10, i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7, i32 8, i32 9, i32 10, i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7, i32 8, i32 9, i32 10, i32 1, i32 2 ]
Extend global merge pass to optionally consider global constant variables. Also add some checks to not merge globals used within landing pad instructions or marked as "used". llvm-svn: 177331
2013-03-19 06:30:07 +08:00
; Global variables marked with "used" attribute must be kept
; CHECK: g8
@g8 = internal global i32 0
@llvm.used = appending global [1 x i8*] [i8* bitcast (i32* @g8 to i8*)], section "llvm.metadata"
; Global used in landing pad instruction must be kept
; CHECK: ZTIi
@_ZTIi = internal global i8* null
Move the personality function from LandingPadInst to Function The personality routine currently lives in the LandingPadInst. This isn't desirable because: - All LandingPadInsts in the same function must have the same personality routine. This means that each LandingPadInst beyond the first has an operand which produces no additional information. - There is ongoing work to introduce EH IR constructs other than LandingPadInst. Moving the personality routine off of any one particular Instruction and onto the parent function seems a lot better than have N different places a personality function can sneak onto an exceptional function. Differential Revision: http://reviews.llvm.org/D10429 llvm-svn: 239940
2015-06-18 04:52:32 +08:00
define i32 @_Z9exceptioni(i32 %arg) personality i8* bitcast (i32 (...)* @__gxx_personality_sj0 to i8*) {
Extend global merge pass to optionally consider global constant variables. Also add some checks to not merge globals used within landing pad instructions or marked as "used". llvm-svn: 177331
2013-03-19 06:30:07 +08:00
bb:
%tmp = invoke i32 @_Z14throwSomethingi(i32 %arg)
to label %bb9 unwind label %bb1
bb1: ; preds = %bb
Move the personality function from LandingPadInst to Function The personality routine currently lives in the LandingPadInst. This isn't desirable because: - All LandingPadInsts in the same function must have the same personality routine. This means that each LandingPadInst beyond the first has an operand which produces no additional information. - There is ongoing work to introduce EH IR constructs other than LandingPadInst. Moving the personality routine off of any one particular Instruction and onto the parent function seems a lot better than have N different places a personality function can sneak onto an exceptional function. Differential Revision: http://reviews.llvm.org/D10429 llvm-svn: 239940
2015-06-18 04:52:32 +08:00
%tmp2 = landingpad { i8*, i32 }
Extend global merge pass to optionally consider global constant variables. Also add some checks to not merge globals used within landing pad instructions or marked as "used". llvm-svn: 177331
2013-03-19 06:30:07 +08:00
catch i8* bitcast (i8** @_ZTIi to i8*)
%tmp3 = extractvalue { i8*, i32 } %tmp2, 1
%tmp4 = tail call i32 @llvm.eh.typeid.for(i8* bitcast (i8** @_ZTIi to i8*))
%tmp5 = icmp eq i32 %tmp3, %tmp4
br i1 %tmp5, label %bb6, label %bb10
bb6: ; preds = %bb1
%tmp7 = extractvalue { i8*, i32 } %tmp2, 0
%tmp8 = tail call i8* @__cxa_begin_catch(i8* %tmp7)
tail call void @__cxa_end_catch()
br label %bb9
bb9: ; preds = %bb6, %bb
%res.0 = phi i32 [ 0, %bb6 ], [ %tmp, %bb ]
ret i32 %res.0
bb10: ; preds = %bb1
resume { i8*, i32 } %tmp2
}
declare i32 @_Z14throwSomethingi(i32)
declare i32 @__gxx_personality_sj0(...)
declare i32 @llvm.eh.typeid.for(i8*)
declare i8* @__cxa_begin_catch(i8*)
declare void @__cxa_end_catch()
[GlobalMerge] Exit early if only one global is to be merged To save some compilation time and prevent some unnecessary changes. Differential Revision: https://reviews.llvm.org/D46640 llvm-svn: 332813
2018-05-20 02:00:02 +08:00
; CHECK: g3:
Change the symbol for merged globals from "merged" to "_MergedGlobals". This makes it more clear that the symbol is an internal, compiler-generated name and gives a little more description about its contents. llvm-svn: 119564
2010-11-18 05:25:33 +08:00
; CHECK: _MergedGlobals:
Fix the ARMGlobalMerge pass to look at variable sizes instead of pointer sizes. It was mistakenly looking at the pointer type when checking for the size of global variables. This is a partial fix for Radar 8673120. llvm-svn: 119563
2010-11-18 05:25:27 +08:00
@g1 = internal global i32 1
@g2 = internal global i32 2
Fix ARMGlobalMerge pass to check if globals are entirely within range. It is generally not sufficient to check if the starting offset is in range of the maximum offset that can be efficiently used for the target. llvm-svn: 119565
2010-11-18 05:25:36 +08:00
; Make sure that the complete variable fits within the range of the maximum
; offset. Having the starting offset in range is not sufficient.
[GlobalMerge] Exit early if only one global is to be merged To save some compilation time and prevent some unnecessary changes. Differential Revision: https://reviews.llvm.org/D46640 llvm-svn: 332813
2018-05-20 02:00:02 +08:00
; When this works properly, @g3 is not merged.
Make GlobalMerge honor the preferred alignment on globals without an explicitly specified alignment. <rdar://problem/10497732>. llvm-svn: 145523
2011-12-01 05:54:15 +08:00
@g3 = internal global [30 x i32] [ i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7, i32 8, i32 9, i32 10, i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7, i32 8, i32 9, i32 10, i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7, i32 8, i32 9, i32 10 ], align 4
Change ARMGlobalMerge to keep BSS globals in separate pools. This completes the fixes for Radar 8673120. llvm-svn: 119566
2010-11-18 05:25:39 +08:00
; Global variables that can be placed in BSS should be kept together in a
; separate pool of merged globals.
[GlobalMerge] Exit early if only one global is to be merged To save some compilation time and prevent some unnecessary changes. Differential Revision: https://reviews.llvm.org/D46640 llvm-svn: 332813
2018-05-20 02:00:02 +08:00
; CHECK: _MergedGlobals.1
Change ARMGlobalMerge to keep BSS globals in separate pools. This completes the fixes for Radar 8673120. llvm-svn: 119566
2010-11-18 05:25:39 +08:00
@g4 = internal global i32 0
@g5 = internal global i32 0
Extend global merge pass to optionally consider global constant variables. Also add some checks to not merge globals used within landing pad instructions or marked as "used". llvm-svn: 177331
2013-03-19 06:30:07 +08:00
; Global variables that are constant can be merged together
[GlobalMerge] Exit early if only one global is to be merged To save some compilation time and prevent some unnecessary changes. Differential Revision: https://reviews.llvm.org/D46640 llvm-svn: 332813
2018-05-20 02:00:02 +08:00
; CHECK: _MergedGlobals.2
Extend global merge pass to optionally consider global constant variables. Also add some checks to not merge globals used within landing pad instructions or marked as "used". llvm-svn: 177331
2013-03-19 06:30:07 +08:00
@g6 = internal constant [12 x i32] zeroinitializer, align 4
@g7 = internal constant [12 x i32] zeroinitializer, align 4