summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Scalar
Commit message (Collapse)AuthorAgeFilesLines
* Refactor insert and extract of sub-integers into static helpers thatChandler Carruth2012-10-181-68/+84
| | | | | | | | | | | | | operate purely on values. Sink the alloca loading and storing logic into the rewrite routines that are specific to alloca-integer-rewrite driving. This is just a refactoring here, but the subsequent step will be to reuse the insertion and extraction logic when rewriting integer loads and stores that have been split and decomposed into narrower loads and stores. No functionality changed other than different names for instructions. llvm-svn: 166176
* This FIXME was fixed some time ago. =]Chandler Carruth2012-10-181-3/+0
| | | | llvm-svn: 166175
* Temporarily revert the TargetTransform changes.Bob Wilson2012-10-181-69/+65
| | | | | | | | | | | The TargetTransform changes are breaking LTO bootstraps of clang. I am working with Nadav to figure out the problem, but I am reverting it for now to get our buildbots working. This reverts svn commits: 165665 165669 165670 165786 165787 165997 and I have also reverted clang svn 165741 llvm-svn: 166168
* This just in, it is a *bad idea* to use 'udiv' on an offset ofChandler Carruth2012-10-171-3/+3
| | | | | | | | | | | a pointer. A very bad idea. Let's not do that. Fixes PR14105. Note that this wasn't *that* glaring of an oversight. Originally, these routines were only called on offsets within an alloca, which are intrinsically positive. But over the evolution of the pass, they ended up being called for arbitrary offsets, and things went downhill... llvm-svn: 166095
* Fix a really annoying "bug" introduced in r165941. The change from thatChandler Carruth2012-10-171-3/+3
| | | | | | | | | | | revision makes no sense. We cannot use the address space of the *post indexed* type to conclude anything about a *pre indexed* pointer type's size. More importantly, this index can never be over a pointer. We are indexing over arrays and vectors here. Of course, I have no test case here. Neither did the original patch. =/ llvm-svn: 166091
* Simplify code. No functionality change.Jakub Staszak2012-10-161-7/+3
| | | | llvm-svn: 166053
* 80-col fixup.Jakub Staszak2012-10-161-1/+2
| | | | llvm-svn: 166050
* Simplify potentially quadratic behavior while erasing elements from std::vector.Jakub Staszak2012-10-161-7/+1
| | | | llvm-svn: 166045
* Use the Attributes::get method which takes an AttrVal value directly to ↵Bill Wendling2012-10-162-30/+11
| | | | | | simplify the code a bit. No functionality change. llvm-svn: 166009
* Move the Attributes::Builder outside of the Attributes class and into its ↵Bill Wendling2012-10-153-12/+12
| | | | | | own class named AttrBuilder. No functionality change. llvm-svn: 165960
* Resubmit the changes to llvm core to update the functions to support ↵Micah Villmow2012-10-152-6/+13
| | | | | | different pointer sizes on a per address space basis. llvm-svn: 165941
* Update the memcpy rewriting to fully support widened int rewriting. ThisChandler Carruth2012-10-151-8/+26
| | | | | | | | includes extracting ints for copying elsewhere and inserting ints when copying into the alloca. This should fix the CanSROA assertion coming out of Clang's regression test suite. llvm-svn: 165931
* Follow-up fix to r165928: handle memset rewriting for widened integers,Chandler Carruth2012-10-151-30/+25
| | | | | | | and generally clean up the memset handling. It had rotted a bit as the other rewriting logic got polished more. llvm-svn: 165930
* First major step toward addressing PR14059. This teaches SROA to handleChandler Carruth2012-10-151-53/+93
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | cases where we have partial integer loads and stores to an otherwise promotable alloca to widen[1] those loads and stores to cover the entire alloca and bitcast them into the appropriate type such that promotion can proceed. These partial loads and stores stem from an annoying confluence of ARM's calling convention and ABI lowering and the FCA pre-splitting which takes place in SROA. Clang lowers a { double, double } in-register function argument as a [4 x i32] function argument to ensure it is placed into integer 32-bit registers (a really unnerving implicit contract between Clang and the ARM backend I would add). This results in a FCA load of [4 x i32]* from the { double, double } alloca, and SROA decomposes this into a sequence of i32 loads and stores. Inlining proceeds, code gets folded, but at the end of the day, we still have i32 stores to the low and high halves of a double alloca. Widening these to be i64 operations, and bitcasting them to double prior to loading or storing allows promotion to proceed for these allocas. I looked quite a bit changing the IR which Clang produces for this case to be more friendly, but small changes seem unlikely to help. I think the best representation we could use currently would be to pass 4 i32 arguments thereby avoiding any FCAs, but that would still require this fix. It seems like it might eventually be nice to somehow encode the ABI register selection choices outside of the parameter type system so that the parameter can be a { double, double }, but the CC register annotations indicate that this should be passed via 4 integer registers. This patch does not address the second problem in PR14059, which is the reverse: when a struct alloca is loaded as a *larger* single integer. This patch also does not address some of the code quality issues with the FCA-splitting. Those don't actually impede any optimizations really, but they're on my list to clean up. [1]: Pedantic footnote: for those concerned about memory model issues here, this is safe. For the alloca to be promotable, it cannot escape or have any use of its address that could allow these loads or stores to be racing. Thus, widening is always safe. llvm-svn: 165928
* Hoist the canConvertValue predicate and the convertValue transform outChandler Carruth2012-10-151-44/+52
| | | | | | | into static helper functions. They're really quite generic and are going to be needed elsewhere shortly. llvm-svn: 165927
* Add an enum for the return and function indexes into the AttrListPtr object. ↵Bill Wendling2012-10-151-15/+23
| | | | | | This gets rid of some magic numbers. llvm-svn: 165924
* Attributes RewriteBill Wendling2012-10-152-10/+10
| | | | | | | | | | Convert the internal representation of the Attributes class into a pointer to an opaque object that's uniqued by and stored in the LLVMContext object. The Attributes class then becomes a thin wrapper around this opaque object. Eventually, the internal representation will be expanded to include attributes that represent code generation options, etc. llvm-svn: 165917
* instcombine: Migrate strcmp and strncmp optimizationsMeador Inge2012-10-151-105/+0
| | | | | | | This patch migrates the strcmp and strncmp optimizations from the simplify-libcalls pass into the instcombine library call simplifier. llvm-svn: 165915
* Unquadratize SetVector removal loops in DSE.Benjamin Kramer2012-10-141-27/+36
| | | | | | | | | Erasing from the beginning or middle of the vector is expensive, remove_if can do it in linear time even though it's a bit ugly without lambdas. No functionality change. llvm-svn: 165903
* Remove the bitwise assignment OR operator from the Attributes class. Replace ↵Bill Wendling2012-10-141-9/+16
| | | | | | it with the equivalent from the builder class. llvm-svn: 165895
* Remove the bitwise XOR operator from the Attributes class. Replace it with ↵Bill Wendling2012-10-141-2/+4
| | | | | | the equivalent from the builder class. llvm-svn: 165893
* instcombine: Migrate strchr and strrchr optimizationsMeador Inge2012-10-131-91/+0
| | | | | | | This patch migrates the strchr and strrchr optimizations from the simplify-libcalls pass into the instcombine library call simplifier. llvm-svn: 165875
* instcombine: Migrate strcat and strncat optimizationsMeador Inge2012-10-131-101/+1
| | | | | | | This patch migrates the strcat and strncat optimizations from the simplify-libcalls pass into the instcombine library call simplifier. llvm-svn: 165874
* Teach SROA to cope with wrapper aggregates. These show up a lot in ABIChandler Carruth2012-10-131-3/+33
| | | | | | | | | | | | | | | | | | | | | | | type coercion code, especially when targetting ARM. Things like [1 x i32] instead of i32 are very common there. The goal of this logic is to ensure that when we are picking an alloca type, we look through such wrapper aggregates and across any zero-length aggregate elements to find the simplest type possible to form a type partition. This logic should (generally speaking) rarely fire. It only ends up kicking in when an alloca is accessed using two different types (for instance, i32 and float), and the underlying alloca type has wrapper aggregates around it. I noticed a significant amount of this occurring looking at stepanov_abstraction generated code for arm, and suspect it happens elsewhere as well. Note that this doesn't yet address truly heinous IR productions such as PR14059 is concerning. Those result in mismatched *sizes* of types in addition to mismatched access and alloca types. llvm-svn: 165870
* Speculatively harden the conversion logic. I have no idea if this willChandler Carruth2012-10-131-0/+11
| | | | | | | | | help the dragonegg builders, and no test case at this point, but this was one dimly plausible case I spotted by inspection. Hopefully will get a testcase from those bots soon-ish, and will tidy this up with proper testing. llvm-svn: 165869
* Silence a warning in -assert builds.Chandler Carruth2012-10-131-0/+1
| | | | llvm-svn: 165867
* Clean up how we rewrite loads and stores to the whole alloca. When theseChandler Carruth2012-10-131-5/+49
| | | | | | | | | | | | are single value types, the load and store should be directly based upon the alloca and then bitcasting can fix the type as needed afterward. This might in theory improve some of the IR coming out of SROA, but I don't expect big changes yet and don't have any test cases on hand. This is really just a cleanup/refactoring patch. The next patch will cause this code path to be hit a lot more, actually get SROA to promote more allocas and include several more test cases. llvm-svn: 165864
* Revert 165732 for further review.Micah Villmow2012-10-112-13/+6
| | | | llvm-svn: 165747
* Add in the first iteration of support for llvm/clang/lldb to allow variable ↵Micah Villmow2012-10-112-6/+13
| | | | | | per address space pointer sizes to be optimized correctly. llvm-svn: 165726
* Add a new interface to allow IR-level passes to access codegen-specific ↵Nadav Rotem2012-10-101-65/+69
| | | | | | information. llvm-svn: 165665
* Remove the final bits of Attributes being declared in the AttributeBill Wendling2012-10-102-2/+5
| | | | | | | namespace. Use the attribute's enum value instead. No functionality change intended. llvm-svn: 165610
* Update EarlyCSE's SimpleValues to use Hashing.h for their hashes. Expanded ↵Michael Ilseman2012-10-091-25/+81
| | | | | | the hashing and equality to allow for equality modulo commutativity for binary ops, and comparisons with swapping of predicates. llvm-svn: 165509
* Use the enum value of the attributes when adding them to the attributes builder.Bill Wendling2012-10-091-9/+9
| | | | llvm-svn: 165494
* Create enums for the different attributes.Bill Wendling2012-10-093-4/+7
| | | | | | | We use the enums to query whether an Attributes object has that attribute. The opaque layer is responsible for knowing where that specific attribute is stored. llvm-svn: 165488
* Fix PR14034, an infloop / heap corruption / crash bug in the new SROA.Chandler Carruth2012-10-091-0/+2
| | | | | | | Thanks to Benjamin for the raw test case. This one took about 50 times longer to reduce than to fix. =/ llvm-svn: 165476
* Fix. Apply the no capture attribute to the correct parameter.Bill Wendling2012-10-091-4/+7
| | | | llvm-svn: 165469
* Convert to using the Attributes::Builder class to create attributes.Bill Wendling2012-10-091-10/+25
| | | | llvm-svn: 165468
* Refactor the AddrMode class out of TLI to its own header file.Nadav Rotem2012-10-081-7/+8
| | | | | | | | This class is used by LSR and a number of places in the codegen. This is the first step in de-coupling LSR from TLI, and creating a new interface in between them. llvm-svn: 165455
* Move TargetData to DataLayout.Micah Villmow2012-10-0819-128/+128
| | | | llvm-svn: 165402
* SROA.cpp: Fix a warning, [-Wunused-variable]NAKAMURA Takumi2012-10-051-0/+1
| | | | llvm-svn: 165309
* Move this test a bit later, after the point at which we know that we eitherDuncan Sands2012-10-051-10/+10
| | | | | | | | have an alloca or a parameter, since then the alloca test should make sense to readers, while before it probably appears too specific. No functionality change. llvm-svn: 165306
* Teach the new SROA a new trick. Now we zap any memcpy or memmoves whichChandler Carruth2012-10-051-42/+93
| | | | | | | | | | | | are in fact identity operations. We detect these and kill their partitions so that even splitting is unaffected by them. This is particularly important because Clang relies on emitting identity memcpy operations for struct copies, and these fold away to constants very often after inlining. Fixes the last big performance FIXME I have on my plate. llvm-svn: 165285
* Lift the speculation visitor above all the helpers that are targeted atChandler Carruth2012-10-051-281/+283
| | | | | | | | | | | the rewrite visitor to make the fact that the speculation is completely independent a bit more clear. I promise that this is just a cut/paste of the one visitor and adding the annonymous namespace wrappings. The diff may look completely preposterous, it does in git for some reason. llvm-svn: 165284
* This patch corrects commit 165126 by using an integer bit width instead of Preston Gurd2012-10-041-2/+3
| | | | | | | | a pointer to a type, in order to remove the uses of getGlobalContext(). Patch by Tyler Nowicki. llvm-svn: 165255
* Add a comment to the commit r165187.Jakub Staszak2012-10-041-1/+3
| | | | llvm-svn: 165238
* In my recent change to avoid use of underaligned memory I didn't notice thatDuncan Sands2012-10-041-7/+7
| | | | | | | | cpyDest can be mutated in some cases, which would then cause a crash later if indeed the memory was underaligned. This brought down several buildbots, so I guess the underaligned case is much more common than I thought! llvm-svn: 165228
* Fix PR13969, a mini-phase-ordering issue with the new SROA pass.Chandler Carruth2012-10-041-23/+50
| | | | | | | | | | | | | | | | | | | | | Currently, we re-visit allocas when something changes about the way they might be *split* to allow better scalarization to take place. However, we weren't handling the case when the *promotion* is what would change the behavior of SROA. When an address derived from an alloca is stored into another alloca, we consider the first to have escaped. If the second is ever promoted to an SSA value, we will suddenly be able to run the SROA pass on the first alloca. This patch adds explicit support for this form if iteration. When we detect a store of a pointer derived from an alloca, we flag the underlying alloca for reprocessing after promotion. The logic works hard to only do this when there is definitely going to be promotion and it might remove impediments to the analysis of the alloca. Thanks to Nick for the great test case and Benjamin for some sanity check review. llvm-svn: 165223
* The memcpy optimizer was happily doing call slot forwarding when the new memoryDuncan Sands2012-10-041-4/+30
| | | | | | | | | | was less aligned than the old. In the testcase this results in an overaligned memset: the memset alignment was correct for the original memory but is too much for the new memory. Fix this by either increasing the alignment of the new memory or bailing out if that isn't possible. Should fix the gcc-4.7 self-host buildbot failure. llvm-svn: 165220
* Teach the integer-promotion rewrite strategy to be endianness aware.Chandler Carruth2012-10-041-9/+29
| | | | | | | | | | | | | | | | | | | | | | | Sorry for this being broken so long. =/ As part of this, switch all of the existing tests to be Little Endian, which is the behavior I was asserting in them anyways! Add in a new big-endian test that checks the interesting behavior there. Another part of this is to tighten the rules abotu when we perform the full-integer promotion. This logic now rejects cases where there fully promoted integer is a non-multiple-of-8 bitwidth or cases where the loads or stores touch bits which are in the allocated space of the alloca but are not loaded or stored when accessing the integer. Sadly, these aren't really observable today as the rest of the pass will already ensure the invariants hold. However, the latter situation is likely to become a potential concern in the future. Thanks to Benjamin and Duncan for early review of this patch. I'm still looking into whether there are further endianness issues, please let me know if anyone sees BE failures persisting past this. llvm-svn: 165219
* Use method to query for attributes.Bill Wendling2012-10-041-1/+1
| | | | llvm-svn: 165209
OpenPOWER on IntegriCloud