summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Analysis/ScalarEvolution.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Get rid of static constructors for pass registration. Instead, every pass ↵Owen Anderson2010-10-191-0/+1
| | | | | | | | | | | | | | | | | exposes an initializeMyPassFunction(), which must be called in the pass's constructor. This function uses static dependency declarations to recursively initialize the pass's dependencies. Clients that only create passes through the createFooPass() APIs will require no changes. Clients that want to use the CommandLine options for passes will need to manually call the appropriate initialization functions in PassInitialization.h before parsing commandline arguments. I have tested this with all standard configurations of clang and llvm-gcc on Darwin. It is possible that there are problems with the static dependencies that will only be visible with non-standard options. If you encounter any crash in pass registration/creation, please send the testcase to me directly. llvm-svn: 116820
* Begin adding static dependence information to passes, which will allow us toOwen Anderson2010-10-121-1/+5
| | | | | | | | | perform initialization without static constructors AND without explicit initialization by the client. For the moment, passes are required to initialize both their (potential) dependencies and any passes they preserve. I hope to be able to relax the latter requirement in the future. llvm-svn: 116334
* Now with fewer extraneous semicolons!Owen Anderson2010-10-071-1/+1
| | | | llvm-svn: 115996
* Don't add the operand count to SCEV uniquing data; FoldingSetNodeIDDan Gohman2010-10-041-5/+0
| | | | | | already knows its own length, so this is redundant. llvm-svn: 115521
* Reapply r112432, now that the real problem is addressed.Dan Gohman2010-08-311-4/+9
| | | | llvm-svn: 112667
* Reapply r112433, now that the real problem is addressed.Dan Gohman2010-08-311-21/+24
| | | | llvm-svn: 112666
* Revert r110916. This patch is buggy because the code inside theDan Gohman2010-08-311-7/+4
| | | | | | inner loop doesn't update all the variables in the outer loop. llvm-svn: 112665
* Revert r112432. It appears to be exposing a problem in the emacs build.Dan Gohman2010-08-311-9/+4
| | | | llvm-svn: 112638
* Speculatively revert r112433.Dan Gohman2010-08-311-24/+21
| | | | llvm-svn: 112608
* Restructure the {A,+,B}<L> * {C,+,D}<L> folding so that it foldsDan Gohman2010-08-291-21/+24
| | | | | | | all applicable addrecs before recursing on getMulExpr, instead of recursing on getMulExpr for each one. llvm-svn: 112433
* Batch up subtracts along with adds, when analyzing long chains ofDan Gohman2010-08-291-4/+9
| | | | | | operations. llvm-svn: 112432
* Micro-optimize GroupByComplexity.Dan Gohman2010-08-291-2/+3
| | | | llvm-svn: 112431
* Hold AddRec->getLoop() in a variable, to make the Mul code more consistentDan Gohman2010-08-291-3/+4
| | | | | | with the Add code. llvm-svn: 112430
* Rename a variable, for consistency.Dan Gohman2010-08-291-5/+8
| | | | llvm-svn: 112429
* Use iterators instead of indices.Dan Gohman2010-08-291-2/+2
| | | | llvm-svn: 112428
* Fix an index calculation thinko.Dan Gohman2010-08-281-1/+1
| | | | llvm-svn: 112337
* When merging adjacent operands, scan ahead and merge all equalDan Gohman2010-08-271-11/+14
| | | | | | adjacent operands at once, instead of just two at a time. llvm-svn: 112299
* Make the {A,+,B}<L> + {C,+,D}<L> --> Other + {A+C,+,B+D}<L>Dan Gohman2010-08-271-23/+21
| | | | | | | | transformation collect all the addrecs with the same loop add combine them at once rather than starting everything over at the first chance. llvm-svn: 112290
* Switch ScalarEvolution's main Value*->SCEV* map from std::mapDan Gohman2010-08-271-28/+26
| | | | | | to DenseMap. llvm-svn: 112281
* Optimize SCEVComplexityCompare. Use a 3-way return instead of a 2-wayDan Gohman2010-08-271-48/+82
| | | | | | | return to avoid needing two calls to test for equivalence, and sort addrecs by their degree before examining their operands. llvm-svn: 112267
* To create a copy of a SmallVector with an element removed from theDan Gohman2010-08-161-6/+7
| | | | | | | | | middle, copy the elements in two groups, rather than copying all the elements and then doing an erase on the middle of the result. These are SmallVectors, so we shouldn't expect to hit dynamic allocation in the common case. llvm-svn: 111151
* Tidy whitespace.Dan Gohman2010-08-161-5/+4
| | | | llvm-svn: 111147
* Add a comment.Dan Gohman2010-08-161-0/+5
| | | | llvm-svn: 111145
* Use const_iterator in a few places.Dan Gohman2010-08-161-3/+3
| | | | llvm-svn: 111144
* Use iterators instead of indices in a few more places.Dan Gohman2010-08-161-6/+9
| | | | llvm-svn: 111143
* Micro-optimize SCEVConstant comparison.Dan Gohman2010-08-161-4/+4
| | | | llvm-svn: 111142
* Move SCEVNAryExpr's virtual member functions out of line, and convertDan Gohman2010-08-161-0/+33
| | | | | | them to iterators. llvm-svn: 111140
* Use iterators instead of indices in simple cases.Dan Gohman2010-08-161-6/+4
| | | | llvm-svn: 111138
* Avoid gratuitous inefficiency in ifndef NDEBUG code.Dan Gohman2010-08-161-8/+8
| | | | llvm-svn: 111137
* Make one getAddExpr call when analyzing a+b+c+d+e+... instead of oneDan Gohman2010-08-161-6/+31
| | | | | | for each add instruction. Ditto for Mul. llvm-svn: 111136
* Delete an unused function.Dan Gohman2010-08-161-35/+0
| | | | llvm-svn: 111135
* Various optimizations. Don't compare two loops' depthsDan Gohman2010-08-131-18/+26
| | | | | | | when they are the same loop. Don't compare two instructions' loop depths when they are in the same block. llvm-svn: 111045
* When testing whether one loop contains another, test this directlyDan Gohman2010-08-131-2/+2
| | | | | | rather than testing whether the loop contains the other's header. llvm-svn: 111039
* Add a const.Dan Gohman2010-08-131-1/+1
| | | | llvm-svn: 111038
* When creating a symmetric SCEV with a constant operand, putDan Gohman2010-08-131-4/+4
| | | | | | | the constant operand on the left, as that's where ScalarEvolution will end up canonicalizing to. llvm-svn: 111037
* An add recurrence is loop-invariant in any loop inside of itsDan Gohman2010-08-131-0/+4
| | | | | | | associated loop. This avoids potentially expensive traversals of the add recurrence's operands. llvm-svn: 111034
* Optimize ScalarEvolution::getAddExpr's operand factoring code byDan Gohman2010-08-121-4/+7
| | | | | | | | having it finish processing all of the muliply operands before starting the whole getAddExpr process over again, instead of immediately after the first simplification. llvm-svn: 110916
* Hoist some loop-invariant code out of a hot loop.Dan Gohman2010-08-121-2/+4
| | | | llvm-svn: 110915
* Optimize ScalarEvolution::getAddExpr's duplicate operand detectionDan Gohman2010-08-121-3/+7
| | | | | | | | by having it finish processing the whole operand list before starting the whole getAddExpr process over again, instead of immediately after the first duplicate is found. llvm-svn: 110914
* When analyzing loop exit conditions combined with and and or, don'tDan Gohman2010-08-111-14/+12
| | | | | | | make any assumptions about when the two conditions will agree on when to permit the loop to exit. This fixes PR7845. llvm-svn: 110758
* Rename and reorder the arguments to isImpliedCond, for consistency and clarity.Dan Gohman2010-08-101-10/+12
| | | | llvm-svn: 110750
* Reapply r110396, with fixes to appease the Linux buildbot gods.Owen Anderson2010-08-061-1/+1
| | | | llvm-svn: 110460
* Revert r110396 to fix buildbots.Owen Anderson2010-08-061-1/+1
| | | | llvm-svn: 110410
* Don't use PassInfo* as a type identifier for passes. Instead, use the ↵Owen Anderson2010-08-051-1/+1
| | | | | | | | address of the static ID member as the sole unique type identifier. Clean up APIs related to this change. llvm-svn: 110396
* Fix a minor bug which resulted in intermediate calculationsDan Gohman2010-08-041-1/+1
| | | | | | using wider types than are necessary. llvm-svn: 110241
* Make SCEVUnknown a CallbackVH, so that it can be notified directlyDan Gohman2010-08-021-47/+46
| | | | | | | | | | | of Value deletions and RAUWs, instead of relying on ScalarEvolution's Scalars map being notified, as that's complicated at best, and insufficient in general. This means SCEVUnknown needs a non-trivial destructor, so introduce a mechanism to allow ScalarEvolution to locate all the SCEVUnknowns. llvm-svn: 110086
* Prefix `next' iterator operation with `llvm::'.Oscar Fuentes2010-08-021-2/+2
| | | | | | | | Fixes potential ambiguity problems on VS 2010. Patch by nobled! llvm-svn: 110029
* Speculatively revert r109705 since it seems to be causing some build botEric Christopher2010-07-291-45/+29
| | | | | | angst. llvm-svn: 109718
* Factor out some of the code for updating old SCEVUnknown values, andDan Gohman2010-07-291-29/+45
| | | | | | | | | extend it to handle the case where multiple RAUWs affect a single SCEVUnknown. Add a ScalarEvolution unittest to test for this situation. llvm-svn: 109705
* Make SCEVCallbackVH::allUsesReplacedWith update the old SCEVUnknownDan Gohman2010-07-281-22/+39
| | | | | | | | | | | | object, as it may still be referenced by SCEVs not cleaned up by the use list traversal. Also, in ScalarEvolution::forgetValue, only check for a SCEVUnknown object for the original value, not for any value in the use list, because other SCEVUnknown values aren't necessary obsolete at that point. llvm-svn: 109570
OpenPOWER on IntegriCloud