summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Analysis
Commit message (Collapse)AuthorAgeFilesLines
* Teach internalize to preserve the callgraph.Duncan Sands2008-10-031-0/+13
| | | | | | Why? Because it was there! llvm-svn: 56996
* Factorize code: remove variants of "strip offDuncan Sands2008-10-012-55/+8
| | | | | | | | | | | pointer bitcasts and GEP's", and centralize the logic in Value::getUnderlyingObject. The difference with stripPointerCasts is that stripPointerCasts only strips GEPs if all indices are zero, while getUnderlyingObject strips GEPs no matter what the indices are. llvm-svn: 56922
* s/ParameterAttributes/Attributes/gDevang Patel2008-09-231-1/+0
| | | | llvm-svn: 56513
* Rationalize the names of passes that print information:Duncan Sands2008-09-232-4/+4
| | | | | | | | | | | | | | | | | -callgraph => print-callgraph -callscc => print-callgraph-sccs -cfgscc => print-cfg-sccs -externalfnconstants => print-externalfnconstants -print => print-function -print-alias-sets (no change) -print-callgraph => dot-callgraph -print-cfg => dot-cfg -print-cfg-only => dot-cfg-only -print-dom-info (no change) -printm => print-module -printusedtypes => print-used-types llvm-svn: 56487
* Initial support for the CMake build system.Oscar Fuentes2008-09-222-0/+36
| | | | llvm-svn: 56419
* Finally re-apply r46959. This is made feasible by the combinationDan Gohman2008-09-161-2/+2
| | | | | | of r56230, r56232, and r56246. llvm-svn: 56247
* Improve instcombine's handling of integer min and max in two ways:Dan Gohman2008-09-161-5/+0
| | | | | | | | | | | | | | | | - Recognize expressions like "x > -1 ? x : 0" as min/max and turn them into expressions like "x < 0 ? 0 : x", which is easily recognizable as a min/max operation. - Refrain from folding expression like "y/2 < 1" to "y < 2" when the comparison is being used as part of a min or max idiom, like "y/2 < 1 ? 1 : y/2". In that case, the division has another use, so folding doesn't eliminate it, and obfuscates the min/max, making it harder to recognize as a min/max operation. These benefit ScalarEvolution, CodeGen, and anything else that wants to recognize integer min and max. llvm-svn: 56246
* Teach ScalarEvolution to consider loop preheaders in the search forDan Gohman2008-09-151-8/+38
| | | | | | | an if statement that guards a loop, to allow indvars to avoid smax operations in more situations. llvm-svn: 56232
* Fix WriteAsOperand to not emit a leading space character. AdjustDan Gohman2008-09-141-4/+4
| | | | | | | | | | | | | | | | | | its callers to emit a space character before calling it when a space is needed. This fixes several spurious whitespace issues in ScalarEvolution's debug dumps. See the test changes for examples. This also fixes odd space-after-tab indentation in the output for switch statements, and changes calls from being printed like this: call void @foo( i32 %x ) to this: call void @foo(i32 %x) llvm-svn: 56196
* Fix PR2792: treat volatile loads as writing memory somewhere.Duncan Sands2008-09-131-3/+11
| | | | | | Treat stores as reading memory, just to play safe. llvm-svn: 56188
* Rather than marking all internal globals "Ref"Duncan Sands2008-09-121-17/+11
| | | | | | | | | | | | | | | | when a readonly declaration is called, set a flag. This is faster and uses less memory. In theory it is less accurate, because before only those internal globals that were read by someone were being marked "Ref", but now all are. But in practice, thanks to other passes, all internal globals of the kind considered here will be both read and stored to: those only read will have been turned into constants, and those only stored to will have been deleted. llvm-svn: 56143
* Fix comment typo.Duncan Sands2008-09-111-1/+1
| | | | llvm-svn: 56116
* Intrinsics don't touch internal global variablesDuncan Sands2008-09-111-2/+4
| | | | | | | (unless passed one via a parameter), even if they are IntrWriteMem. llvm-svn: 56115
* Intrinsics don't read these kinds of globalDuncan Sands2008-09-111-5/+7
| | | | | | variables. llvm-svn: 56105
* Simplify this some more. No functionality change.Duncan Sands2008-09-091-15/+8
| | | | llvm-svn: 56003
* Optimization suggested by Matthijs Kooijman.Duncan Sands2008-09-091-1/+2
| | | | llvm-svn: 55988
* Correct callgraph construction. It has two problems:Duncan Sands2008-09-091-34/+14
| | | | | | | | | | | | | | | | | | | (1) code left over from the days of ConstantPointerRef: if a use of a function is a GlobalValue then that is not considered a reason to add an edge from the external node, even though the use may be as an initializer for an externally visible global! There might be some point to this behaviour when the use is by an alias (though the code predated aliases by some centuries), but I think PR2782 is a better way of handling that. (2) If function F calls function G, and also G is a parameter to the call, then an F->G edge is not added to the callgraph. While this doesn't seem to matter much, adding such an edge makes the callgraph more regular. In addition, the new code should be faster as well as simpler. llvm-svn: 55987
* Didn't mean to commit this change to how theDuncan Sands2008-09-081-8/+4
| | | | | | callgraph is printed. llvm-svn: 55912
* Reapply 55859. This doesn't change anything asDuncan Sands2008-09-081-14/+8
| | | | | | | long as the callgraph is correct. It checks for wrong callgraphs more strictly. llvm-svn: 55894
* When PruneEH turned an invoke into an ordinaryDuncan Sands2008-09-061-1/+14
| | | | | | | | | | | | call (thus changing the call site) it didn't inform the callgraph about this. But the call site does matter - as shown by the testcase, the callgraph become invalid after the inliner ran (with an edge between two functions simply missing), resulting in wrong deductions by GlobalsModRef. llvm-svn: 55872
* Revert r55859. This is breaking the build in the abscence of its companion ↵Owen Anderson2008-09-051-0/+10
| | | | | | commit. llvm-svn: 55865
* Delete the removeCallEdgeTo callgraph method,Duncan Sands2008-09-051-10/+0
| | | | | | | | | | | | | | | because it does not maintain a correct list of callsites. I discovered (see following commit) that the inliner will create a wrong callgraph if it is fed a callgraph with correct edges but incorrect callsites. These were created by Prune-EH, and while it wasn't done via removeCallEdgeTo, it could have been done via removeCallEdgeTo, which is an accident waiting to happen. Use removeCallEdgeFor instead. llvm-svn: 55859
* Neaten this up a bit. No functionality change.Duncan Sands2008-09-041-15/+14
| | | | llvm-svn: 55789
* Tidy up several unbeseeming casts from pointer to intptr_t.Dan Gohman2008-09-0415-21/+21
| | | | llvm-svn: 55779
* If a SCC has a node without a function, then the SCCDuncan Sands2008-09-031-9/+14
| | | | | | | | | | analysis would bail out without removing function records for other members of the SCC (which may exist if those functions read or wrote global variables). Since these are initialized to "readnone", this resulted in incorrect alias analysis results. llvm-svn: 55714
* Fix maxo bado thinko.Duncan Sands2008-09-031-1/+1
| | | | llvm-svn: 55700
* Since onlyReadsMemory returns true if in factDuncan Sands2008-09-031-2/+4
| | | | | | | | doesNotAccessMemory, check doesNotAccessMemory first, since otherwise functions may be marked readonly rather than readnone. llvm-svn: 55697
* Cleanup GlobalsModRef a bit. When analysing theDuncan Sands2008-09-031-104/+108
| | | | | | | | | | | callgraph, when one member of a SCC calls another then the analysis would drop to mod-ref because there is (usually) no function info for the callee yet; fix this. Teach the analysis about function attributes, in particular the readonly attribute (which requires being careful about globals). llvm-svn: 55696
* rename destroy -> releaseMemory to properly hook into passmgr.Chris Lattner2008-08-281-2/+2
| | | | llvm-svn: 55508
* Clear the intervals list in "destroy", patch by Chris Lattner2008-08-281-0/+1
| | | | | | Prakash Prabhu! llvm-svn: 55458
* Switch the asmprinter (.ll) and all the stuff it requires over toChris Lattner2008-08-231-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | use raw_ostream instead of std::ostream. Among other goodness, this speeds up llvm-dis of kc++ with a release build from 0.85s to 0.49s (88% faster). Other interesting changes: 1) This makes Value::print be non-virtual. 2) AP[S]Int and ConstantRange can no longer print to ostream directly, use raw_ostream instead. 3) This fixes a bug in raw_os_ostream where it didn't flush itself when destroyed. 4) This adds a new SDNode::print method, instead of only allowing "dump". A lot of APIs have both std::ostream and raw_ostream versions, it would be useful to go through and systematically anihilate the std::ostream versions. This passes dejagnu, but there may be minor fallout, plz let me know if so and I'll fix it. llvm-svn: 55263
* Temporarily reverting r55137. This was causing the bootstrap to go into anBill Wendling2008-08-211-7/+3
| | | | | | infinite loop. llvm-svn: 55149
* Fix ComputeMaskedBits to handle phis correctly. We need to take theDavid Greene2008-08-211-3/+7
| | | | | | minimum of the known zeros. llvm-svn: 55137
* Don't use the result of WriteAsOperand or WriteTypeSymbolic.Chris Lattner2008-08-192-5/+10
| | | | llvm-svn: 54977
* Remove GCSE, ValueNumbering, and LoadValueNumbering. These have been ↵Owen Anderson2008-08-152-816/+0
| | | | | | deprecated for almost a year; it's finally time for them to go away. llvm-svn: 54822
* Fix a bogus srem rule - a negative value srem'd by a power-of-2Dan Gohman2008-08-131-5/+3
| | | | | | | can have a non-negative result; for example, -16%16 is 0. Also, clarify the related comments. This fixes PR2670. llvm-svn: 54767
* Teach constant folding that an inttoptr of aDuncan Sands2008-08-131-0/+13
| | | | | | | ptrtoint can be turned into a bitcast if the integer is at least as wide as a pointer. llvm-svn: 54752
* Extend ScalarEvolution's executesAtLeastOnce logic to be able toDan Gohman2008-08-121-55/+57
| | | | | | | | continue past the first conditional branch when looking for a relevant test. This helps it avoid using MAX expressions in loop trip counts in more cases. llvm-svn: 54697
* "This patch adds a virtual call to AbstractLatticeFunction to derive a Chris Lattner2008-08-091-1/+3
| | | | | | | | | type lattice value for an Argument*, giving clients the opportunity to use something other than Top for it if they choose to." Patch by John McCall! llvm-svn: 54589
* Canonicalize nested AddRecs in by nesting them in order of loop depth.Dan Gohman2008-08-081-0/+13
| | | | llvm-svn: 54545
* Don't call getAnalysisUsage unless -debug-pass is enabled. This speedsChris Lattner2008-08-082-8/+4
| | | | | | up the passmgr by avoiding useless work. llvm-svn: 54528
* PR2621: Improvements to the SCEV AddRec binomial expansion. This Eli Friedman2008-08-041-84/+111
| | | | | | | | | | | | | | | | | | | | | | | | | version uses a new algorithm for evaluating the binomial coefficients which is significantly more efficient for AddRecs of more than 2 terms (see the comments in the code for details on how the algorithm works). It also fixes some bugs: it removes the arbitrary length restriction for AddRecs, it fixes the silent generation of incorrect code for AddRecs which require a wide calculation width, and it fixes an issue where we were incorrectly truncating the iteration count too far when evaluating an AddRec expression narrower than the induction variable. There are still a few related issues I know of: I think there's still an issue with the SCEVExpander expansion of AddRec in terms of the width of the induction variable used. The hack to avoid generating too-wide integers shouldn't be necessary; instead, the callers should be considering the cost of the expansion before expanding it (in addition to not expanding too-wide integers, we might not want to expand expressions that are really expensive, especially when optimizing for size; calculating an length-17 32-bit AddRec currently generates about 250 instructions of straight-line code on X86). Also, for long 32-bit AddRecs on X86, CodeGen really sucks at scheduling the code. I'm planning on filing follow-up PRs for these issues. llvm-svn: 54332
* Another SCEV issue from PR2607; essentially the same issue, but this Eli Friedman2008-07-301-4/+4
| | | | | | | | | | | time applying to the implicit comparison in smin expressions. The correct way to transform an inequality into the opposite inequality, either signed or unsigned, is with a not expression. I looked through the SCEV code, and I don't think there are any more occurrences of this issue. llvm-svn: 54194
* Fix for PR2607: SCEV miscomputing the loop count for loops with an Eli Friedman2008-07-301-3/+7
| | | | | | | | | | | | SGT exit condition. Essentially, the correct way to flip an inequality in 2's complement is the not operator, not the negation operator. That said, the difference only affects cases involving INT_MIN. Also, enhance the pre-test search logic to be a bit smarter about inequalities flipped with a not operator, so it can eliminate the smax from the iteration count for simple loops. llvm-svn: 54184
* Fix a subtle bug when removing instructions from memdep. In very specific Owen Anderson2008-07-281-0/+4
| | | | | | | | circumstances we could end up remapping a dependee to the same instruction that we're trying to remove. Handle this properly by just falling back to a conservative solution. llvm-svn: 54132
* Fix minor issues with VICmp/VFCmp constant expressionsNate Begeman2008-07-251-1/+3
| | | | llvm-svn: 54030
* Revert r53812 -- premature. LegalizeTypes isn't actually on yet!Nick Lewycky2008-07-211-8/+22
| | | | llvm-svn: 53816
* Switch on the use of arbitrary precision integers in scalar evolution. This willNick Lewycky2008-07-211-22/+8
| | | | | | | | | | bail after 256-bits to avoid producing code that the backends can't handle. Previously, we capped it at 64-bits, preferring to miscompile in those cases. This change also reverts much of r52248 because the invariants the code was expecting are now being met. llvm-svn: 53812
* This header isn't necessary now.Wojciech Matyjewicz2008-07-201-2/+0
| | | | llvm-svn: 53811
* Fix PR2088. Use modulo linear equation solver to compute loop iterationWojciech Matyjewicz2008-07-201-22/+71
| | | | | | count. llvm-svn: 53810
OpenPOWER on IntegriCloud