summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Scalar/ScalarReplAggregates.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Use > instead of >=. We want to promote aggregates of 128-bytes.Bill Wendling2009-03-031-1/+1
| | | | llvm-svn: 65960
* Reapply r65755, but reversing "<" to ">=".Bill Wendling2009-03-031-2/+3
| | | | llvm-svn: 65945
* Temporarily revert r65755. It was causing failures in the self-hostingBill Wendling2009-03-011-5/+3
| | | | | | | | | | | | | | | | | | | | | testsuite: Running /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/test/CodeGen/X86/dg.exp ... FAIL: /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/test/CodeGen/X86/nancvt.ll Failed with exit(1) at line 2 while running: grep 2147027116 nancvt.ll.tmp | count 3 count: expected 3 lines and got 0. child process exited abnormally FAIL: /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/test/CodeGen/X86/vec_ins_extract.ll Failed with exit(1) at line 1 while running: llvm-as < /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/test/CodeGen/X86/vec_ins_extract.ll | opt -scalarrepl -instcombine | llc -march=x86 -mcpu=yonah | not /usr/bin/grep sub.*esp subl $28, %esp subl $28, %esp child process exited abnormally And more. llvm-svn: 65758
* hoist the check for alloca size up so that it controls CanConvertToScalar Chris Lattner2009-03-011-3/+5
| | | | | | as well as isSafeAllocaToScalarRepl. llvm-svn: 65755
* Use early exits. Reduce indentation.Devang Patel2009-02-101-37/+42
| | | | llvm-svn: 64226
* Enable scalar replacement of AllocaInst whose one of the user is dbg info.Devang Patel2009-02-101-52/+81
| | | | llvm-svn: 64207
* fix PR3489, use bits instead of bytes.Chris Lattner2009-02-061-2/+2
| | | | llvm-svn: 63916
* teach "convert from scalar" to handle loads of fca's.Chris Lattner2009-02-031-2/+29
| | | | llvm-svn: 63659
* refactor the interface to ConvertUsesOfLoadToScalar, Chris Lattner2009-02-031-34/+35
| | | | | | renaming it to ConvertScalar_ExtractValue llvm-svn: 63658
* convert ConvertUsesOfLoadToScalar to use IRBuilder,Chris Lattner2009-02-031-37/+33
| | | | | | no functionality change. llvm-svn: 63652
* switch ConvertScalar_InsertValue to use an IRBuilder, no Chris Lattner2009-02-031-30/+32
| | | | | | functionality change. llvm-svn: 63651
* make scalar conversion handle stores of first classChris Lattner2009-02-031-22/+38
| | | | | | | aggregate values. loads are not yet handled (coming soon to an sroa near you). llvm-svn: 63649
* Make SROA produce a vector only when the alloca is actually Chris Lattner2009-02-031-7/+20
| | | | | | | | | | | | | | | | | | | accessed at least once as a vector. This prevents it from compiling the example in not-a-vector into: define double @test(double %A, double %B) { %tmp4 = insertelement <7 x double> undef, double %A, i32 0 %tmp = insertelement <7 x double> %tmp4, double %B, i32 4 %tmp2 = extractelement <7 x double> %tmp, i32 4 ret double %tmp2 } instead, producing the integer code. Producing vectors when they aren't otherwise in the program is dangerous because a lot of other code treats them carefully and doesn't want to break them down. OTOH, many things want to break down tasty i448's. llvm-svn: 63638
* add another case of undefined behavior without crashing, PR3466.Chris Lattner2009-02-031-2/+3
| | | | llvm-svn: 63620
* Teach ConvertUsesToScalar to handle memset, allowing it to handle Chris Lattner2009-02-031-21/+55
| | | | | | | | | | | | | | crazy cases like: struct f { int A, B, C, D, E, F; }; short test4() { struct f A; A.A = 1; memset(&A.B, 2, 12); return A.C; } llvm-svn: 63596
* rearrange how SRoA handles promotion of allocas to vectors.Chris Lattner2009-02-031-93/+120
| | | | | | | | | | With the new world order, it can handle cases where the first store into the alloca is an element of the vector, instead of requiring the first analyzed store to have the vector type itself. This allows us to un-xfail test/CodeGen/X86/vec_ins_extract.ll. llvm-svn: 63590
* inline SROA::ConvertToScalar, no functionality change.Chris Lattner2009-02-021-20/+14
| | | | llvm-svn: 63544
* Fix a bug which caused us to miscompile a couple of AdaChris Lattner2009-02-021-1/+6
| | | | | | tests. Thanks for the beautiful reduced testcase Duncan! llvm-svn: 63529
* Fix a comment (bytes -> bits), reformat a commentDuncan Sands2009-02-021-29/+29
| | | | | | | and remove trailing whitespace. No functionality change. llvm-svn: 63511
* Fix an obvious thinko.Duncan Sands2009-02-021-1/+1
| | | | llvm-svn: 63510
* Simplify and generalize the SROA "convert to scalar" transformation toChris Lattner2009-01-311-317/+174
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | be able to handle *ANY* alloca that is poked by loads and stores of bitcasts and GEPs with constant offsets. Before the code had a number of annoying limitations and caused it to miss cases such as storing into holes in structs and complex casts (as in bitfield-sroa) where we had unions of bitfields etc. This also handles a number of important cases that are exposed due to the ABI lowering stuff we do to pass stuff by value. One case that is pretty great is that we compile 2006-11-07-InvalidArrayPromote.ll into: define i32 @func(<4 x float> %v0, <4 x float> %v1) nounwind { %tmp10 = call <4 x i32> @llvm.x86.sse2.cvttps2dq(<4 x float> %v1) %tmp105 = bitcast <4 x i32> %tmp10 to i128 %tmp1056 = zext i128 %tmp105 to i256 %tmp.upgrd.43 = lshr i256 %tmp1056, 96 %tmp.upgrd.44 = trunc i256 %tmp.upgrd.43 to i32 ret i32 %tmp.upgrd.44 } which turns into: _func: subl $28, %esp cvttps2dq %xmm1, %xmm0 movaps %xmm0, (%esp) movl 12(%esp), %eax addl $28, %esp ret Which is pretty good code all things considering :). One effect of this is that SROA will start generating arbitrary bitwidth integers that are a multiple of 8 bits. In the case above, we got a 256 bit integer, but the codegen guys assure me that it can handle the simple and/or/shift/zext stuff that we're doing on these operations. This addresses rdar://6532315 llvm-svn: 63469
* Fix some issues with volatility, move "CanConvertToScalar" check Chris Lattner2009-01-281-21/+33
| | | | | | after the others. llvm-svn: 63227
* Rename getABITypeSize to getTypePaddedSize, asDuncan Sands2009-01-121-22/+23
| | | | | | suggested by Chris. llvm-svn: 62099
* Fix PR3304Chris Lattner2009-01-091-2/+12
| | | | llvm-svn: 61995
* This implements the second half of the fix for PR3290, handlingChris Lattner2009-01-081-2/+99
| | | | | | | | | loads from allocas that cover the entire aggregate. This handles some memcpy/byval cases that are produced by llvm-gcc. This triggers a few times in kc++ (with std::pair<std::_Rb_tree_const_iterator <kc::impl_abstract_phylum*>,bool>) and once in 176.gcc (with %struct..0anon). llvm-svn: 61915
* Implement the first half of PR3290: if there is a store of an Chris Lattner2009-01-071-5/+133
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | integer to a (transitive) bitcast the alloca and if that integer has the full size of the alloca, then it clobbers the whole thing. Handle this by extracting pieces out of the stored integer and filing them away in the SROA'd elements. This triggers fairly frequently because the CFE uses integers to pass small structs by value and the inliner exposes these. For example, in kimwitu++, I see a bunch of these with i64 stores to "%struct.std::pair<std::_Rb_tree_const_iterator<kc::impl_abstract_phylum*>,bool>" In 176.gcc I see a few i32 stores to "%struct..0anon". In the testcase, this is a difference between compiling test1 to: _test1: subl $12, %esp movl 20(%esp), %eax movl %eax, 4(%esp) movl 16(%esp), %eax movl %eax, (%esp) movl (%esp), %eax addl 4(%esp), %eax addl $12, %esp ret vs: _test1: movl 8(%esp), %eax addl 4(%esp), %eax ret The second half of this will be to handle loads of the same form. llvm-svn: 61853
* Factor a bunch of code out into a helper method.Chris Lattner2009-01-071-148/+156
| | | | llvm-svn: 61852
* use continue to simplify code and reduce nesting, no functionalityChris Lattner2009-01-071-38/+58
| | | | | | change. llvm-svn: 61851
* Get TargetData once up front and cache as an ivar instead ofChris Lattner2009-01-071-45/+38
| | | | | | requerying it all over the place. llvm-svn: 61850
* Use the hasAllZeroIndices predicate to simplify some Chris Lattner2009-01-071-28/+6
| | | | | | code, no functionality change. llvm-svn: 61849
* Allow SROA of vectors. Removing this caused aDale Johannesen2008-11-041-12/+4
| | | | | | | huge performance regression in something we care about. This may not be final fix. llvm-svn: 58718
* Allow scalarrepl to treat an all-zero GEP just as bitcast.Matthijs Kooijman2008-10-061-14/+28
| | | | | | | This includes not marking a GEP involving a vector as unsafe, but only when it has all zero indices. This allows scalarrepl to work in a few more cases. llvm-svn: 57177
* Tidy up several unbeseeming casts from pointer to intptr_t.Dan Gohman2008-09-041-1/+1
| | | | llvm-svn: 55779
* Fix PR2423 by checking all indices for out of range access, not only Chris Lattner2008-08-231-35/+31
| | | | | | | indices that start with an array subscript. x->field[10000] is just as bad as (*X)[14][10000]. llvm-svn: 55226
* minor tidying of comments.Chris Lattner2008-06-231-12/+14
| | | | llvm-svn: 52630
* Fix PR2369 by making scalarrepl more careful about promoting Chris Lattner2008-06-221-5/+14
| | | | | | | | | structures. Its default threshold is to promote things that are smaller than 128 bytes, which is sane. However, it is not sane to do this for things that turn into 128 *registers*. Add a cap on the number of registers introduced, defaulting to 128/4=32. llvm-svn: 52611
* Learn ScalarReplAggregrates how stores and loads of first class aggregratesMatthijs Kooijman2008-06-051-0/+51
| | | | | | | | | | work and how to replace them into individual values. Also, when trying to replace an aggregrate that is used by load or store with a single (large) integer, don't crash (but don't replace the aggregrate either). Also adds a testcase for both structs and arrays. llvm-svn: 51997
* Change packed struct layout so that field sizesDuncan Sands2008-06-041-7/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | are the same as in unpacked structs, only field positions differ. This only matters for structs containing x86 long double or an apint; it may cause backwards compatibility problems if someone has bitcode containing a packed struct with a field of one of those types. The issue is that only 10 bytes are needed to hold an x86 long double: the store size is 10 bytes, but the ABI size is 12 or 16 bytes (linux/ darwin) which comes from rounding the store size up by the alignment. Because it seemed silly not to pack an x86 long double into 10 bytes in a packed struct, this is what was done. I now think this was a mistake. Reserving the ABI size for an x86 long double field even in a packed struct makes things more uniform: the ABI size is now always used when reserving space for a type. This means that developers are less likely to make mistakes. It also makes life easier for the CBE which otherwise could not represent all LLVM packed structs (PR2402). Front-end people might need to adjust the way they create LLVM structs - see following change to llvm-gcc. llvm-svn: 51928
* Use isSingleValueType instead of isFirstClassType toDan Gohman2008-05-231-1/+1
| | | | | | exclude struct and array types. llvm-svn: 51456
* API change for {BinaryOperator|CmpInst|CastInst}::create*() --> Create. ↵Gabor Greif2008-05-161-6/+6
| | | | | | Legacy interfaces will be in place for some time. (Merge from use-diet branch.) llvm-svn: 51200
* Clean up the use of static and anonymous namespaces. This turned upDan Gohman2008-05-131-3/+3
| | | | | | | several things that were neither in an anonymous namespace nor static but not intended to be global. llvm-svn: 51017
* API changes for class Use size reduction, wave 1.Gabor Greif2008-04-061-19/+19
| | | | | | | | Specifically, introduction of XXX::Create methods for Users that have a potentially variable number of Uses. llvm-svn: 49277
* fix a bug Anders ran into where scalarrepl would crash when promotingChris Lattner2008-02-291-57/+68
| | | | | | | | a union containing a vector and an array whose elements were smaller than the vector elements. this means we need to compile the load of the array elements into an extract element plus a truncate. llvm-svn: 47752
* Refactor some code out of ConvertUsesToScalar into their own methods, noChris Lattner2008-02-291-148/+190
| | | | | | functionality change. llvm-svn: 47751
* Fix scalarrepl to not 'miscompile' undefined code, part #2.Chris Lattner2008-02-101-1/+1
| | | | | | | This fixes the store case, my previous patch just fixed the load case. rdar://5707076. llvm-svn: 46932
* Fix a bug where scalarrepl would discard offset if type would match.Chris Lattner2008-01-301-2/+2
| | | | | | | In practice this can only happen on code with already undefined behavior, but this is still a good thing to handle correctly. llvm-svn: 46539
* Remove attribution from file headers, per discussion on llvmdev.Chris Lattner2007-12-291-2/+2
| | | | llvm-svn: 45418
* At the point of calculating the shift amount, theDuncan Sands2007-11-061-2/+3
| | | | | | | type of SV has changed from what it originally was. However we need the store width of the original. llvm-svn: 43775
* If a long double is in a packed struct, it may beDuncan Sands2007-11-051-5/+7
| | | | | | that there is no padding. llvm-svn: 43691
* Change uses of getTypeSize to getABITypeSize, getTypeStoreSizeDuncan Sands2007-11-041-44/+56
| | | | | | | | | | | | | | | | | | | | | | or getTypeSizeInBits as appropriate in ScalarReplAggregates. The right change to make was not always obvious, so it would be good to have an sroa guru review this. While there I noticed some bugs, and fixed them: (1) arrays of x86 long double have holes due to alignment padding, but this wasn't being spotted by HasStructPadding (renamed to HasPadding). The same goes for arrays of oddly sized ints. Vectors also suffer from this, in fact the problem for vectors is much worse because basic vector assumptions seem to be broken by vectors of type with alignment padding. I didn't try to fix any of these vector problems. (2) The code for extracting smaller integers from larger ones (in the "int union" case) was wrong on big-endian machines for integers with size not a multiple of 8, like i1. Probably this is impossible to hit via llvm-gcc, but I fixed it anyway while there and added a testcase. I also got rid of some trailing whitespace and changed a function name which had an obvious typo in it. llvm-svn: 43672
OpenPOWER on IntegriCloud