summaryrefslogtreecommitdiffstats
path: root/llvm/test/CodeGen/ARM/global-merge.ll
Commit message (Collapse)AuthorAgeFilesLines
* [GlobalMerge] Exit early if only one global is to be mergedHaicheng Wu2018-05-191-4/+4
| | | | | | | | To save some compilation time and prevent some unnecessary changes. Differential Revision: https://reviews.llvm.org/D46640 llvm-svn: 332813
* ARM: Do not use llc -march in tests.Matthias Braun2017-08-011-1/+1
| | | | | | | | | | | | | | | `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
* Move the personality function from LandingPadInst to FunctionDavid Majnemer2015-06-171-2/+2
| | | | | | | | | | | | | | | | | | | 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
* Changed renaming of local symbols by inserting a dot vefore the numeric suffix.Sunil Srivastava2015-05-121-3/+3
| | | | | | | One code change and several test changes to match that details in http://reviews.llvm.org/D9481 llvm-svn: 237150
* [GlobalMerge] Look at uses to create smaller global sets.Ahmed Bougacha2015-04-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [AArch64, ARM] Enable GlobalMerge with -O3 rather than -O1.Ahmed Bougacha2015-03-231-1/+1
| | | | | | | | | | | | | | | | | | | | The pass used to be enabled by default with CodeGenOpt::Less (-O1). This is too aggressive, considering the pass indiscriminately merges all globals together. Currently, performance doesn't always improve, and, on code that uses few globals (e.g., the odd file- or function- static), more often than not is degraded by the optimization. Lengthy discussion can be found on llvmdev (AArch64-focused; ARM has similar problems): http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-February/082800.html Also, it makes tooling and debuggers less useful when dealing with globals and data sections. GlobalMerge needs to better identify those cases that benefit, and this will be done separately. In the meantime, move the pass to run with -O3 rather than -O1, on both ARM and AArch64. llvm-svn: 233024
* Extend global merge pass to optionally consider global constant variables.Quentin Colombet2013-03-181-1/+52
| | | | | | Also add some checks to not merge globals used within landing pad instructions or marked as "used". llvm-svn: 177331
* Make GlobalMerge honor the preferred alignment on globals without an ↵Eli Friedman2011-11-301-1/+1
| | | | | | | | explicitly specified alignment. <rdar://problem/10497732>. llvm-svn: 145523
* Enable GlobalMerge on darwin.Devang Patel2011-03-231-1/+0
| | | | llvm-svn: 128183
* XFAIL for all. These tests are darwin specific anyway.Devang Patel2011-03-041-1/+1
| | | | llvm-svn: 127022
* Disable ARMGlobalMerge on darwin. The debugger is not yet able to extract ↵Devang Patel2011-03-041-0/+1
| | | | | | individual variable's info from merged global. llvm-svn: 127019
* Change ARMGlobalMerge to keep BSS globals in separate pools.Bob Wilson2010-11-171-1/+7
| | | | | | This completes the fixes for Radar 8673120. llvm-svn: 119566
* Fix ARMGlobalMerge pass to check if globals are entirely within range.Bob Wilson2010-11-171-0/+6
| | | | | | | 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
* Change the symbol for merged globals from "merged" to "_MergedGlobals".Bob Wilson2010-11-171-1/+1
| | | | | | | 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
* Fix the ARMGlobalMerge pass to look at variable sizes instead of pointer sizes.Bob Wilson2010-11-171-0/+11
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
OpenPOWER on IntegriCloud