aboutsummaryrefslogtreecommitdiffstats
path: root/test/Transforms/ScalarRepl
Commit message (Collapse)AuthorAgeFilesLines
* Do some simple copy propagation through integer loads and stores when promotingCameron Zwarich2011-03-292-1/+54
| | | | | | | vector types. This helps a lot with inlined functions when using the ARM soft float ABI. Fixes <rdar://problem/9184212>. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128453 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix a typo and add a test.Cameron Zwarich2011-03-261-0/+15
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128331 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix PR9464 by correcting some math that just happened to be right in most casesCameron Zwarich2011-03-231-0/+16
| | | | | | that were hit in practice. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128146 91177308-0d34-0410-b5e6-96231b3b80d8
* Only convert allocas to scalars if it is profitable. The profitability metric ICameron Zwarich2011-03-161-0/+27
| | | | | | | | | | | chose is having a non-memcpy/memset use and being larger than any native integer type. Originally I chose having an access of a size smaller than the total size of the alloca, but this caused some minor issues on the spirit benchmark where SRoA runs again after some inlining. This fixes <rdar://problem/8613163>. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@127718 91177308-0d34-0410-b5e6-96231b3b80d8
* Add native integer type TargetData to some existing tests.Cameron Zwarich2011-03-162-2/+2
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@127717 91177308-0d34-0410-b5e6-96231b3b80d8
* Add a test case for r127320.Cameron Zwarich2011-03-091-0/+14
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@127321 91177308-0d34-0410-b5e6-96231b3b80d8
* Add support to scalar replacement for partial vector accesses of an alloca, e.g.Cameron Zwarich2011-03-091-0/+59
| | | | | | | | | | | | | | | | | a union of a float, <2 x float>, and <4 x float>. This mostly comes up with the use of vector intrinsics, especially in NEON when programmers know the layout of the register file. This enables codegen to eliminate a lot of the subregister traffic it would otherwise generate. This commit only enables this for a small number of floating-point cases, but a lot more integer cases. I assume this is okay for all ports, but I did not do extensive testing of the quality of code involving i512 vectors and the like. If there is a use case where this generates worse code than before, let me know and we can scale it back. This fixes <rdar://problem/9036264>. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@127317 91177308-0d34-0410-b5e6-96231b3b80d8
* merge all the "crash tests" into crash.llChris Lattner2011-01-2415-293/+240
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@124101 91177308-0d34-0410-b5e6-96231b3b80d8
* fix PR9017, a bug where we'd assert when promoting in unreachableChris Lattner2011-01-241-0/+20
| | | | | | | code. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@124100 91177308-0d34-0410-b5e6-96231b3b80d8
* enhance SRoA to promote allocas that are used by PHI nodes. This oftenChris Lattner2011-01-241-3/+24
| | | | | | | | | | | occurs because instcombine sinks loads and inserts phis. This kicks in on such apps as 175.vpr, eon, 403.gcc, xalancbmk and a bunch of times in spec2006 in some app that uses std::deque. This resolves the last of rdar://7339113. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@124090 91177308-0d34-0410-b5e6-96231b3b80d8
* Enhance SRoA to promote allocas that are used by selects in someChris Lattner2011-01-231-4/+58
| | | | | | | | | | | | | | | | | | | | | | common cases. This triggers a surprising number of times in SPEC2K6 because min/max idioms end up doing this. For example, code from the STL ends up looking like this to SRoA: %202 = load i64* %__old_size, align 8, !tbaa !3 %203 = load i64* %__old_size, align 8, !tbaa !3 %204 = load i64* %__n, align 8, !tbaa !3 %205 = icmp ult i64 %203, %204 %storemerge.i = select i1 %205, i64* %__n, i64* %__old_size %206 = load i64* %storemerge.i, align 8, !tbaa !3 We can now promote both the __n and the __old_size allocas. This addresses another chunk of rdar://7339113, poor codegen on stringswitch. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@124088 91177308-0d34-0410-b5e6-96231b3b80d8
* Enhance SRoA to be more aggressive about scalarization of aggregate allocasChris Lattner2011-01-231-0/+78
| | | | | | | | | | | | | | that have PHI or select uses of their element pointers. This can often happen when instcombine sinks two loads into a successor, inserting a phi or select. With this patch, we can scalarize the alloca, but the pinned elements are not yet promoted. This is still a win for large aggregates where only one element is used. This fixes rdar://8904039 and part of rdar://7339113 (poor codegen on stringswitch). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@124070 91177308-0d34-0410-b5e6-96231b3b80d8
* remove an old hack that avoided creating MMX datatypes. TheChris Lattner2011-01-231-4/+2
| | | | | | | X86 backend has been fixed. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@124064 91177308-0d34-0410-b5e6-96231b3b80d8
* if an alloca is only ever accessed as a unit, and is accessed with ↵Chris Lattner2011-01-161-2/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | load/store instructions, then don't try to decimate it into its individual pieces. This will just make a mess of the IR and is pointless if none of the elements are individually accessed. This was generating really terrible code for std::bitset (PR8980) because it happens to be lowered by clang as an {[8 x i8]} structure instead of {i64}. The testcase now is optimized to: define i64 @test2(i64 %X) { br label %L2 L2: ; preds = %0 ret i64 %X } before we generated: define i64 @test2(i64 %X) { %sroa.store.elt = lshr i64 %X, 56 %1 = trunc i64 %sroa.store.elt to i8 %sroa.store.elt8 = lshr i64 %X, 48 %2 = trunc i64 %sroa.store.elt8 to i8 %sroa.store.elt9 = lshr i64 %X, 40 %3 = trunc i64 %sroa.store.elt9 to i8 %sroa.store.elt10 = lshr i64 %X, 32 %4 = trunc i64 %sroa.store.elt10 to i8 %sroa.store.elt11 = lshr i64 %X, 24 %5 = trunc i64 %sroa.store.elt11 to i8 %sroa.store.elt12 = lshr i64 %X, 16 %6 = trunc i64 %sroa.store.elt12 to i8 %sroa.store.elt13 = lshr i64 %X, 8 %7 = trunc i64 %sroa.store.elt13 to i8 %8 = trunc i64 %X to i8 br label %L2 L2: ; preds = %0 %9 = zext i8 %1 to i64 %10 = shl i64 %9, 56 %11 = zext i8 %2 to i64 %12 = shl i64 %11, 48 %13 = or i64 %12, %10 %14 = zext i8 %3 to i64 %15 = shl i64 %14, 40 %16 = or i64 %15, %13 %17 = zext i8 %4 to i64 %18 = shl i64 %17, 32 %19 = or i64 %18, %16 %20 = zext i8 %5 to i64 %21 = shl i64 %20, 24 %22 = or i64 %21, %19 %23 = zext i8 %6 to i64 %24 = shl i64 %23, 16 %25 = or i64 %24, %22 %26 = zext i8 %7 to i64 %27 = shl i64 %26, 8 %28 = or i64 %27, %25 %29 = zext i8 %8 to i64 %30 = or i64 %29, %28 ret i64 %30 } In this case, instcombine was able to eliminate the nonsense, but in PR8980 enough PHIs are in play that instcombine backs off. It's better to not generate this stuff in the first place. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@123571 91177308-0d34-0410-b5e6-96231b3b80d8
* Extend SROA to handle arrays accessed as homogeneous structs and vice versa.Bob Wilson2011-01-131-3/+26
| | | | | | | | | | | | | | | | | This is a minor extension of SROA to handle a special case that is important for some ARM NEON operations. Some of the NEON intrinsics return multiple values, which are handled as struct types containing multiple elements of the same vector type. The corresponding return types declared in the arm_neon.h header have equivalent arrays. We need SROA to recognize that it can split up those arrays and structs into separate vectors, even though they are not always accessed with the same type. SROA already handles loads and stores of an entire alloca by using insertvalue/extractvalue to access the individual pieces, and that code works the same regardless of whether the type is a struct or an array. So, all that needs to be done is to check for compatible arrays and homogeneous structs. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@123381 91177308-0d34-0410-b5e6-96231b3b80d8
* Make SROA more aggressive with allocas containing padding.Bob Wilson2011-01-131-1/+28
| | | | | | | SROA only split up structs and arrays one level at a time, so padding can only cause trouble if it is located in between the struct or array elements. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@123380 91177308-0d34-0410-b5e6-96231b3b80d8
* Treat a call of function pointer like a load of the pointer when consideringNick Lewycky2010-11-241-0/+13
| | | | | | | | whether the pointer can be replaced with the global variable it is a copy of. Fixes PR8680. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120126 91177308-0d34-0410-b5e6-96231b3b80d8
* allow eliminating an alloca that is just copied from an constant globalChris Lattner2010-11-181-0/+13
| | | | | | | | | if it is passed as a byval argument. The byval argument will just be a read, so it is safe to read from the original global instead. This allows us to promote away the %agg.tmp alloca in PR8582 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@119686 91177308-0d34-0410-b5e6-96231b3b80d8
* enhance the "alloca is just a memcpy from constant global"Chris Lattner2010-11-181-0/+13
| | | | | | | | to ignore calls that obviously can't modify the alloca because they are readonly/readnone. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@119683 91177308-0d34-0410-b5e6-96231b3b80d8
* fix a small oversight in the "eliminate memcpy from constant global"Chris Lattner2010-11-181-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | optimization. If the alloca that is "memcpy'd from constant" also has a memcpy from *it*, ignore it: it is a load. We now optimize the testcase to: define void @test2() { %B = alloca %T %a = bitcast %T* @G to i8* %b = bitcast %T* %B to i8* call void @llvm.memcpy.p0i8.p0i8.i64(i8* %b, i8* %a, i64 124, i32 4, i1 false) call void @bar(i8* %b) ret void } previously we would generate: define void @test() { %B = alloca %T %b = bitcast %T* %B to i8* %G.0 = getelementptr inbounds %T* @G, i32 0, i32 0 %tmp3 = load i8* %G.0, align 4 %G.1 = getelementptr inbounds %T* @G, i32 0, i32 1 %G.15 = bitcast [123 x i8]* %G.1 to i8* %1 = bitcast [123 x i8]* %G.1 to i984* %srcval = load i984* %1, align 1 %B.0 = getelementptr inbounds %T* %B, i32 0, i32 0 store i8 %tmp3, i8* %B.0, align 4 %B.1 = getelementptr inbounds %T* %B, i32 0, i32 1 %B.12 = bitcast [123 x i8]* %B.1 to i8* %2 = bitcast [123 x i8]* %B.1 to i984* store i984 %srcval, i984* %2, align 1 call void @bar(i8* %b) ret void } git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@119682 91177308-0d34-0410-b5e6-96231b3b80d8
* filecheckizeChris Lattner2010-11-181-2/+9
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@119681 91177308-0d34-0410-b5e6-96231b3b80d8
* deepen my MMX/SRoA hack to avoid hurting non-x86 codegen.Chris Lattner2010-09-011-0/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112763 91177308-0d34-0410-b5e6-96231b3b80d8
* add a gross hack to work around a problem that Argiris reportedChris Lattner2010-09-011-0/+14
| | | | | | | | | | | | | | on llvmdev: SRoA is introducing MMX datatypes like <1 x i64>, which then cause random problems because the X86 backend is producing mmx stuff without inserting proper emms calls. In the short term, force off MMX datatypes. In the long term, the X86 backend should not select generic vector types to MMX registers. This is being worked on, but won't be done in time for 2.8. rdar://8380055 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112696 91177308-0d34-0410-b5e6-96231b3b80d8
* filecheckizeChris Lattner2010-09-011-3/+25
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112695 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix the second half of PR7437: scalarrepl wasn't preservingChris Lattner2010-07-081-0/+35
| | | | | | | address spaces when SRoA'ing memcpy's. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107846 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove arm_apcscc from the test files. It is the default and doing thisRafael Espindola2010-06-172-3/+3
| | | | | | matches what llvm-gcc and clang now produce. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@106221 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove the arm_aapcscc marker from the tests. It is the defaultRafael Espindola2010-06-151-1/+1
| | | | | | for the linux targets. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@106029 91177308-0d34-0410-b5e6-96231b3b80d8
* move comment.Chris Lattner2010-04-161-1/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101433 91177308-0d34-0410-b5e6-96231b3b80d8
* fix PR6832: we were using the alignment of a pointer when we Chris Lattner2010-04-161-0/+32
| | | | | | | wanted the alignment of the pointee. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101432 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove tests that checks @llvm.dbg.stoppoint handling.Devang Patel2010-03-011-3961/+0
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97493 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix a crash in scalarrepl for memcpy/memmove where the source and destinationBob Wilson2010-01-191-0/+18
| | | | | | | | | | are the same. I had already fixed a similar problem where the source and destination were different bitcasts derived from the same alloca, but the previous fix still did not handle the case where both operands are exactly the same value. Radar 7552893. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@93848 91177308-0d34-0410-b5e6-96231b3b80d8
* Delete useless trailing semicolons.Dan Gohman2010-01-051-1/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@92740 91177308-0d34-0410-b5e6-96231b3b80d8
* Generalize SROA to allow the first index of a GEP to be non-zero. Add aBob Wilson2009-12-221-0/+53
| | | | | | | | | missing check that an array reference doesn't go past the end of the array, and remove some redundant checks for in-bound array and vector references that are no longer needed. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91897 91177308-0d34-0410-b5e6-96231b3b80d8
* Reapply 91459 with a simple fix for the problem that broke the x86_64-darwinBob Wilson2009-12-181-0/+89
| | | | | | | | bootstrap. This also replaces the WeakVH references that Chris objected to with normal Value references. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91711 91177308-0d34-0410-b5e6-96231b3b80d8
* Re-revert 91459. It's breaking the x86_64 darwin bootstrap.Bob Wilson2009-12-171-89/+0
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91607 91177308-0d34-0410-b5e6-96231b3b80d8
* Reapply r91459, it was only unmasking the bug, and since TOT is still broken ↵Daniel Dunbar2009-12-161-0/+89
| | | | | | having it reverted does no good. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91559 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "Reapply 91184 with fixes and an addition to the testcase to cover theDaniel Dunbar2009-12-161-89/+0
| | | | | | | | | problem", this broke llvm-gcc bootstrap for release builds on x86_64-apple-darwin10. This reverts commit db22309800b224a9f5f51baf76071d7a93ce59c9. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91534 91177308-0d34-0410-b5e6-96231b3b80d8
* Reapply 91184 with fixes and an addition to the testcase to cover the problemBob Wilson2009-12-151-0/+89
| | | | | | | | | | | found last time. Instead of trying to modify the IR while iterating over it, I've change it to keep a list of WeakVH references to dead instructions, and then delete those instructions later. I also added some special case code to detect and handle the situation when both operands of a memcpy intrinsic are referencing the same alloca. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91459 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove empty file completelyShantonu Sen2009-12-141-0/+0
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91277 91177308-0d34-0410-b5e6-96231b3b80d8
* revert r91184, because it causes a crash on a .bc file I justChris Lattner2009-12-141-68/+0
| | | | | | | sent to Bob. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91268 91177308-0d34-0410-b5e6-96231b3b80d8
* Revise scalar replacement to be more flexible about handle bitcasts and GEPs.Bob Wilson2009-12-111-0/+68
| | | | | | | | | | | | | | | | While scanning through the uses of an alloca, keep track of the current offset relative to the start of the alloca, and check memory references to see if the offset & size correspond to a component within the alloca. This has the nice benefit of unifying much of the code from isSafeUseOfAllocation, isSafeElementUse, and isSafeUseOfBitCastedAllocation. The code to rewrite the uses of a promoted alloca, after it is determined to be safe, is reorganized in the same way. Also, when rewriting GEP instructions, mark them as "in-bounds" since all the indices are known to be safe. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91184 91177308-0d34-0410-b5e6-96231b3b80d8
* fix PR5436 by making the 'simple' case of SRoA not promote out of range Chris Lattner2009-11-271-2/+34
| | | | | | | | | | | array indexes. The "complex" case of SRoA still handles them, and correctly. This fixes a weirdness where we'd correctly avoid transforming A[0][42] if the 42 was too large, but we'd only do it if it was one gep, not two separate ones. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@90007 91177308-0d34-0410-b5e6-96231b3b80d8
* filecheckizeChris Lattner2009-11-271-5/+10
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@90006 91177308-0d34-0410-b5e6-96231b3b80d8
* Make opt default to not adding a target data string and update tests that ↵Kenneth Uildriks2009-11-0318-0/+18
| | | | | | depend on target data to supply it within the test git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85900 91177308-0d34-0410-b5e6-96231b3b80d8
* Change tests from "opt %s" to "opt < %s" so that opt doesn't see theDan Gohman2009-09-1154-64/+64
| | | | | | | | | input filename so that opt doesn't print the input filename in the output so that grep lines in the tests don't unintentionally match strings in the input filename. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81537 91177308-0d34-0410-b5e6-96231b3b80d8
* Use opt -S instead of piping bitcode output through llvm-dis.Dan Gohman2009-09-0838-48/+48
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81257 91177308-0d34-0410-b5e6-96231b3b80d8
* Change these tests to feed the assembly files to opt directly, insteadDan Gohman2009-09-0854-64/+64
| | | | | | | of using llvm-as, now that opt supports this. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81226 91177308-0d34-0410-b5e6-96231b3b80d8
* Don't crash trying to promote VLAs.Nick Lewycky2009-08-171-0/+23
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79226 91177308-0d34-0410-b5e6-96231b3b80d8
* Split the Add, Sub, and Mul instruction opcodes into separateDan Gohman2009-06-044-47/+47
| | | | | | | | | | | | | | | | integer and floating-point opcodes, introducing FAdd, FSub, and FMul. For now, the AsmParser, BitcodeReader, and IRBuilder all preserve backwards compatability, and the Core LLVM APIs preserve backwards compatibility for IR producers. Most front-ends won't need to change immediately. This implements the first step of the plan outlined here: http://nondot.org/sabre/LLVMNotes/IntegerOverflow.txt git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72897 91177308-0d34-0410-b5e6-96231b3b80d8
* PR4286: Make RewriteLoadUserOfWholeAlloca and Eli Friedman2009-06-011-0/+17
| | | | | | | | | | RewriteStoreUserOfWholeAlloca deal with tail padding because isSafeUseOfBitCastedAllocation expects them to. Otherwise, we crash trying to erase the bitcast. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72688 91177308-0d34-0410-b5e6-96231b3b80d8