summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Analysis/LazyValueInfo.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Move isKnownNonNull out of AliasAnalysis.h and into ValueTracking.cpp sinceDan Gohman2013-01-311-1/+0
| | | | | | | it isn't really an AliasAnalysis concept, and ValueTracking has similar things that it could plausibly share code with some day. llvm-svn: 174027
* Move all of the header files which are involved in modelling the LLVM IRChandler Carruth2013-01-021-4/+4
| | | | | | | | | | | | | | | | | | | | | into their new header subdirectory: include/llvm/IR. This matches the directory structure of lib, and begins to correct a long standing point of file layout clutter in LLVM. There are still more header files to move here, but I wanted to handle them in separate commits to make tracking what files make sense at each layer easier. The only really questionable files here are the target intrinsic tablegen files. But that's a battle I'd rather not fight today. I've updated both CMake and Makefile build systems (I think, and my tests think, but I may have missed something). I've also re-sorted the includes throughout the project. I'll be committing updates to Clang, DragonEgg, and Polly momentarily. llvm-svn: 171366
* Use the new script to sort the includes of every file under lib.Chandler Carruth2012-12-031-7/+7
| | | | | | | | | | | | | | | | | Sooooo many of these had incorrect or strange main module includes. I have manually inspected all of these, and fixed the main module include to be the nearest plausible thing I could find. If you own or care about any of these source files, I encourage you to take some time and check that these edits were sensible. I can't have broken anything (I strictly added headers, and reordered them, never removed), but they may not be the headers you'd really like to identify as containing the API being implemented. Many forward declarations and missing includes were added to a header files to allow them to parse cleanly when included first. The main module rule does in fact have its merits. =] llvm-svn: 169131
* Hoist out some work done inside a loop doing a linear scan over allNick Lewycky2012-10-261-12/+17
| | | | | | | | | | | | instructions in a block. GetUnderlyingObject is more expensive than it looks as it can, for instance, call SimplifyInstruction. This might have some behavioural changes in odd corner cases, but only because of some strange artefacts of the original implementation. If you were relying on those, we can fix that by replacing this with a smarter algorithm. Change passes the existing tests. llvm-svn: 166754
* Move TargetData to DataLayout.Micah Villmow2012-10-081-4/+4
| | | | llvm-svn: 165402
* Revert 'Fix a typo 'iff' => 'if''. iff is an abreviation of if and only if. ↵Sylvestre Ledru2012-09-271-2/+2
| | | | | | See: http://en.wikipedia.org/wiki/If_and_only_if Commit 164767 llvm-svn: 164768
* Fix a typo 'iff' => 'if'Sylvestre Ledru2012-09-271-2/+2
| | | | llvm-svn: 164767
* JumpThreading: when default destination is the destination of some cases in aManman Ren2012-09-051-3/+6
| | | | | | | | | switch, make sure we include the value for the cases when calculating edge value from switch to the default destination. rdar://12241132 llvm-svn: 163270
* Reduce duplicated hash map lookups.Benjamin Kramer2012-08-221-2/+4
| | | | llvm-svn: 162362
* make LazyValueInfo analyze the default case of switch statements (we know ↵Nuno Lopes2012-06-281-16/+15
| | | | | | that in the default branch the value cannot be any of the switch cases) llvm-svn: 159353
* make LVI::getEdgeValue() always intersect the constraints of the edge with ↵Nuno Lopes2012-06-281-36/+53
| | | | | | the range of the block. Previously it was only performing the intersection for a few cases, thus losing precision llvm-svn: 159320
* allow LazyValueInfo::getEdgeValue() to reason about multiple edges from the ↵Nuno Lopes2012-05-181-11/+6
| | | | | | same switch instruction by doing union of ranges (which may still be conservative, but it's more aggressive than before) llvm-svn: 157071
* minor simplification in the call to ConstantRange constructorNuno Lopes2012-05-171-1/+1
| | | | llvm-svn: 157024
* llvm::SwitchInstStepan Dyatkovskiy2012-03-111-1/+1
| | | | | | | Renamed methods caseBegin, caseEnd and caseDefault with case_begin, case_end, and case_default. Added some notes relative to case iterators. llvm-svn: 152532
* Taken into account Duncan's comments for r149481 dated by 2nd Feb 2012:Stepan Dyatkovskiy2012-03-081-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120130/136146.html Implemented CaseIterator and it solves almost all described issues: we don't need to mix operand/case/successor indexing anymore. Base iterator class is implemented as a template since it may be initialized either from "const SwitchInst*" or from "SwitchInst*". ConstCaseIt is just a read-only iterator. CaseIt is read-write iterator; it allows to change case successor and case value. Usage of iterator allows totally remove resolveXXXX methods. All indexing convertions done automatically inside the iterator's getters. Main way of iterator usage looks like this: SwitchInst *SI = ... // intialize it somehow for (SwitchInst::CaseIt i = SI->caseBegin(), e = SI->caseEnd(); i != e; ++i) { BasicBlock *BB = i.getCaseSuccessor(); ConstantInt *V = i.getCaseValue(); // Do something. } If you want to convert case number to TerminatorInst successor index, just use getSuccessorIndex iterator's method. If you want initialize iterator from TerminatorInst successor index, use CaseIt::fromSuccessorIndex(...) method. There are also related changes in llvm-clients: klee and clang. llvm-svn: 152297
* LVI: Recognize the form instcombine canonicalizes range checks into when ↵Benjamin Kramer2012-03-021-4/+16
| | | | | | | | | | forming constant ranges. This could probably be made a lot smarter, but this is a common case and doesn't require LVI to scan a lot of code. With this change CVP can optimize away the "shift == 0" case in Hashing.h that only gets hit when "shift" is in a range not containing 0. llvm-svn: 151919
* SwitchInst refactoring.Stepan Dyatkovskiy2012-02-011-2/+2
| | | | | | | | | | | | | | | | | The purpose of refactoring is to hide operand roles from SwitchInst user (programmer). If you want to play with operands directly, probably you will need lower level methods than SwitchInst ones (TerminatorInst or may be User). After this patch we can reorganize SwitchInst operands and successors as we want. What was done: 1. Changed semantics of index inside the getCaseValue method: getCaseValue(0) means "get first case", not a condition. Use getCondition() if you want to resolve the condition. I propose don't mix SwitchInst case indexing with low level indexing (TI successors indexing, User's operands indexing), since it may be dangerous. 2. By the same reason findCaseValue(ConstantInt*) returns actual number of case value. 0 means first case, not default. If there is no case with given value, ErrorIndex will returned. 3. Added getCaseSuccessor method. I propose to avoid usage of TerminatorInst::getSuccessor if you want to resolve case successor BB. Use getCaseSuccessor instead, since internal SwitchInst organization of operands/successors is hidden and may be changed in any moment. 4. Added resolveSuccessorIndex and resolveCaseIndex. The main purpose of these methods is to see how case successors are really mapped in TerminatorInst. 4.1 "resolveSuccessorIndex" was created if you need to level down from SwitchInst to TerminatorInst. It returns TerminatorInst's successor index for given case successor. 4.2 "resolveCaseIndex" converts low level successors index to case index that curresponds to the given successor. Note: There are also related compatability fix patches for dragonegg, klee, llvm-gcc-4.0, llvm-gcc-4.2, safecode, clang. llvm-svn: 149481
* Remove dead code.Bill Wendling2012-01-181-45/+0
| | | | llvm-svn: 148384
* A DenseMap of a std::map isn't a very good idea because the "grow()" method willBill Wendling2012-01-121-2/+2
| | | | | | | need to make a deep copy of each of the std::maps. Use a std::map of the std::map instead. This improves the compile time of sqlite3 by ~2%. llvm-svn: 148003
* Revert r147978. A DenseMap's iterators may become invalidated here.Bill Wendling2012-01-111-1/+2
| | | | llvm-svn: 147980
* Use a DenseMap.Bill Wendling2012-01-111-2/+1
| | | | | | This appears to improve sqlite3's compile time by ~2%. llvm-svn: 147978
* Clear the new cache.Benjamin Kramer2011-12-031-0/+1
| | | | llvm-svn: 145771
* Add a "seen blocks" cache to LVI to avoid a linear scan over the whole cache ↵Benjamin Kramer2011-12-031-1/+13
| | | | | | | | | just to remove no blocks from the maps. -15% on ARMDisassembler.cpp (Release build). It's not that great to add another layer of caching to the caching-heavy LVI but I don't see a better way. llvm-svn: 145770
* Fix a few more places where TargetData/TargetLibraryInfo is not being passed.Chad Rosier2011-12-021-9/+23
| | | | | | Add FIXMEs to places that are non-trivial to fix. llvm-svn: 145661
* land David Blaikie's patch to de-constify Type, with a few tweaks.Chris Lattner2011-07-181-3/+3
| | | | llvm-svn: 135375
* llvm.memcpy.* has two distinct associated address spaces; the source address ↵Eli Friedman2011-05-311-4/+6
| | | | | | space, and the destination address space. Fix up the interface on MemIntrinsic and MemTransferInst to make this clear, and fix InstructionDereferencesPointer in LazyValueInfo.cpp to use the interface properly. llvm-svn: 132356
* Remove unused STL header includes.Jay Foad2011-04-231-1/+0
| | | | llvm-svn: 130068
* Mark some functions as used which are used within debug-only code. ThisChandler Carruth2011-04-181-0/+2
| | | | | | silences Clang's -Wunused-function when building in release mode. llvm-svn: 129709
* Teach LazyValueInfo that allocas aren't NULL. Over all of llvm-test, this savesNick Lewycky2011-01-151-5/+27
| | | | | | | | | | | half a million non-local queries, each of which would otherwise have triggered a linear scan over a basic block. Also fix a fixme for memory intrinsics which dereference pointers. With this, we prove that a pointer is non-null because it was dereferenced by an intrinsic 112 times in llvm-test. llvm-svn: 123533
* Reorder, rename, and document some members to make this easier to follow.Owen Anderson2011-01-051-20/+23
| | | | llvm-svn: 122929
* When computing the value on an edge, in certain cases LVI would fail to ↵Owen Anderson2011-01-051-0/+5
| | | | | | | | compute the value range in the predecessor block, leading to an incorrect conclusion for the edge value. Found by inspection. llvm-svn: 122908
* Re-convert several of LazyValueInfo's internal maps to Dense{Map|Set}, and ↵Owen Anderson2011-01-051-33/+93
| | | | | | | | | fix the issue in hasBlockValue() that was causing iterator invalidations. Many thanks to Dimitry Andric for tracking down those invalidations! llvm-svn: 122906
* Speculatively revert the use of DenseMap in LazyValueInfo, which may be ↵Owen Anderson2010-12-201-42/+16
| | | | | | causing Linux self-host failures. llvm-svn: 122291
* Attempt to appease the DragonEgg buildbots.Owen Anderson2010-12-201-22/+24
| | | | llvm-svn: 122288
* Convert one of LVI's primary maps to a DenseMap, now that we know are more ↵Owen Anderson2010-12-201-16/+40
| | | | | | assured of iterator stability. llvm-svn: 122273
* More LVI cleanups, including trying to simplify the process of maintaining ↵Owen Anderson2010-12-201-25/+41
| | | | | | the OverDefinedCache. llvm-svn: 122256
* Reuse the reference into the LVI cache throughout the solver subsystem. ↵Owen Anderson2010-12-201-24/+28
| | | | | | | | This is much easier to verify as being safe thanks its recent de-recursivization. llvm-svn: 122254
* Make LazyValueInfo non-recursive.Nick Lewycky2010-12-181-132/+249
| | | | llvm-svn: 122120
* Move Value::getUnderlyingObject to be a standaloneDan Gohman2010-12-151-2/+3
| | | | | | | function so that it can live in Analysis instead of VMCore. llvm-svn: 121885
* Clean up some of LVI:Nick Lewycky2010-12-151-91/+101
| | | | | | | | * mergeIn now uses constant folding for constants that are provably not-equal. * sink some sanity checks from the get*() methods into the mark*() methods, to ensure that we never have a constant/notconstant ConstantInt * some textual cleanups, whitespace changes, removing "else" after return, that sort of thing. llvm-svn: 121877
* Take the first step towards making LVI non-recursive: get rid of the ↵Owen Anderson2010-12-091-101/+39
| | | | | | LVIQuery abstraction. llvm-svn: 121357
* Now with fewer extraneous semicolons!Owen Anderson2010-10-071-1/+1
| | | | llvm-svn: 115996
* It is possible, under specific circumstances involving ptrtoint ↵Owen Anderson2010-09-161-3/+7
| | | | | | | | | | | | ConstantExpr's, for LVI to end up trying to merge a Constant into a ConstantRange. Handle this conservatively for now, rather than asserting. The testcase is more complex that I would like, but the manifestation of the problem is sensitive to iteration orders and the state of the LVI cache, and I have not been able to reproduce it with manually constructed or simplified cases. Fixes PR8162. llvm-svn: 114103
* Clean up some of the PassRegistry implementation, and pImpl-ize it to reduce ↵Owen Anderson2010-09-071-0/+2
| | | | | | | | #include clutter and exposing internal details. llvm-svn: 113252
* Add completely hokey binary-and and binary-or operations to ConstantRange andNick Lewycky2010-09-071-0/+6
| | | | | | teach LazyValueInfo to use them. llvm-svn: 113196
* zap dead code.Chris Lattner2010-09-041-4/+0
| | | | llvm-svn: 113073
* Add support for simplifying a load from a computed value to a load from a ↵Owen Anderson2010-09-031-2/+11
| | | | | | | | global when it is provable that they're equivalent. This fixes PR4855. llvm-svn: 112994
* Remove incorrect and poorly tested code for trying to reason about values on ↵Owen Anderson2010-09-021-16/+2
| | | | | | | | default edges of switches. Just return the conservatively correct answer. llvm-svn: 112876
* Fix a bug in LazyValueInfo that CorrelatedValuePropagation exposed: In the ↵Owen Anderson2010-09-021-4/+0
| | | | | | | | LVI lattice, undef and the full set ConstantRange should not be treated as equivalent. llvm-svn: 112843
* It is possible to try to merge a not-constant with a constantrage, when ↵Owen Anderson2010-08-301-2/+3
| | | | | | | | | dealing with ptrtoint ConstantExpr's. Unfortunately, the only testcase I have for this is huge and doesn't reduce well because the error is sensitive to iteration-order issues, since the problem only occurs when merging values in a particular order. llvm-svn: 112489
OpenPOWER on IntegriCloud