summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Analysis
Commit message (Collapse)AuthorAgeFilesLines
* Consistent use of the noduplicate attribute.Eli Bendersky2014-03-173-5/+5
| | | | | | | | | The "noduplicate" attribute of call instructions is sometimes queried directly and sometimes through the cannotDuplicate() predicate. This patch streamlines all queries to use the cannotDuplicate() predicate. It also adds this predicate to InvokeInst, to mirror what CallInst has. llvm-svn: 204049
* Remove some dead assignements found by scan-buildArnaud A. de Grandmaison2014-03-151-6/+1
| | | | llvm-svn: 204013
* PR17473:Michael Zolotukhin2014-03-121-3/+21
| | | | | | | Don't normalize an expression during postinc transformation unless it's invertible. llvm-svn: 203719
* Test commitMichael Zolotukhin2014-03-121-0/+1
| | | | llvm-svn: 203716
* IR: add a second ordering operand to cmpxhg for failureTim Northover2014-03-111-1/+1
| | | | | | | | | | | | | | | The syntax for "cmpxchg" should now look something like: cmpxchg i32* %addr, i32 42, i32 3 acquire monotonic where the second ordering argument gives the required semantics in the case that no exchange takes place. It should be no stronger than the first ordering constraint and cannot be either "release" or "acq_rel" (since no store will have taken place). rdar://problem/15996804 llvm-svn: 203559
* [TTI] There is actually no realistic way to pop TTI implementations offChandler Carruth2014-03-101-10/+0
| | | | | | | | | | | | | | the stack of the analysis group because they are all immutable passes. This is made clear by Craig's recent work to use override systematically -- we weren't overriding anything for 'finalizePass' because there is no such thing. This is kind of a lame restriction on the API -- we can no longer push and pop things, we just set up the stack and run. However, I'm not invested in building some better solution on top of the existing (terrifying) immutable pass and legacy pass manager. llvm-svn: 203437
* [LCG] Ran clang-format over this too and it pointed out some fixes.Chandler Carruth2014-03-101-4/+6
| | | | llvm-svn: 203435
* [LCG] Simplify a bunch of the LCG code with range for loops and auto.Chandler Carruth2014-03-091-37/+29
| | | | | | | Still more work to be done here to leverage C++11, but this clears out the glaring issues. llvm-svn: 203395
* [C++11] Add range based accessors for the Use-Def chain of a Value.Chandler Carruth2014-03-0913-83/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This requires a number of steps. 1) Move value_use_iterator into the Value class as an implementation detail 2) Change it to actually be a *Use* iterator rather than a *User* iterator. 3) Add an adaptor which is a User iterator that always looks through the Use to the User. 4) Wrap these in Value::use_iterator and Value::user_iterator typedefs. 5) Add the range adaptors as Value::uses() and Value::users(). 6) Update *all* of the callers to correctly distinguish between whether they wanted a use_iterator (and to explicitly dig out the User when needed), or a user_iterator which makes the Use itself totally opaque. Because #6 requires churning essentially everything that walked the Use-Def chains, I went ahead and added all of the range adaptors and switched them to range-based loops where appropriate. Also because the renaming requires at least churning every line of code, it didn't make any sense to split these up into multiple commits -- all of which would touch all of the same lies of code. The result is still not quite optimal. The Value::use_iterator is a nice regular iterator, but Value::user_iterator is an iterator over User*s rather than over the User objects themselves. As a consequence, it fits a bit awkwardly into the range-based world and it has the weird extra-dereferencing 'operator->' that so many of our iterators have. I think this could be fixed by providing something which transforms a range of T&s into a range of T*s, but that *can* be separated into another patch, and it isn't yet 100% clear whether this is the right move. However, this change gets us most of the benefit and cleans up a substantial amount of code around Use and User. =] llvm-svn: 203364
* [C++11] Convert sort predicates into lambdas.Benjamin Kramer2014-03-071-10/+7
| | | | | | No functionality change. llvm-svn: 203288
* Allow constant folding of round function whenever feasibleKarthik Bhat2014-03-071-0/+7
| | | | llvm-svn: 203198
* Teach lint about address spacesMatt Arsenault2014-03-061-6/+5
| | | | llvm-svn: 203132
* Replace OwningPtr<T> with std::unique_ptr<T>.Ahmed Charles2014-03-061-1/+1
| | | | | | | | | | This compiles with no changes to clang/lld/lldb with MSVC and includes overloads to various functions which are used by those projects and llvm which have OwningPtr's as parameters. This should allow out of tree projects some time to move. There are also no changes to libs/Target, which should help out of tree targets have time to move, if necessary. llvm-svn: 203083
* Allow constant folding of copysignKarthik Bhat2014-03-061-0/+7
| | | | llvm-svn: 203076
* [Layering] Move InstVisitor.h into the IR library as it is prettyChandler Carruth2014-03-064-4/+4
| | | | | | obviously coupled to the IR. llvm-svn: 203064
* [Layering] Move DebugInfo.h into the IR library where its implementationChandler Carruth2014-03-061-1/+1
| | | | | | already lives. llvm-svn: 203046
* ConstantFolding: Also fold the vector overloads of our math intrinsics.Benjamin Kramer2014-03-051-34/+73
| | | | llvm-svn: 202997
* Add missing parenthesis in SCEV commentTobias Grosser2014-03-051-1/+1
| | | | | Contributed-by: Michael Zolutukin <mzolotukhin@apple.com> llvm-svn: 202963
* [C++11] Make this interface accept const Use pointers and use overrideChandler Carruth2014-03-052-7/+7
| | | | | | | | to ensure we don't mess up any of the overrides. Necessary for cleaning up the Value use iterators and enabling range-based traversing of use lists. llvm-svn: 202958
* [C++11] Add 'override' keyword to virtual methods that override their base ↵Craig Topper2014-03-0522-133/+130
| | | | | | class. llvm-svn: 202945
* Allow constant folding of fma and fmuladdMatt Arsenault2014-03-051-0/+27
| | | | llvm-svn: 202914
* Fix duplicate code in ConstantFoldingMatt Arsenault2014-03-051-54/+33
| | | | llvm-svn: 202913
* [Modules] Move the ConstantRange class into the IR library. This isChandler Carruth2014-03-044-4/+4
| | | | | | | | | | a bit surprising, as the class is almost entirely abstracted away from any particular IR, however it encodes the comparsion predicates which mutate ranges as ICmp predicate codes. This is reasonable as they're used for both instructions and constants. Thus, it belongs in the IR library with instructions and constants. llvm-svn: 202838
* [Modules] Move the PredIteratorCache into the IR library -- it isChandler Carruth2014-03-041-1/+1
| | | | | | hardcoded to use IR BasicBlocks. llvm-svn: 202835
* [Modules] Move CFG.h to the IR library as it defines graph traits overChandler Carruth2014-03-046-6/+6
| | | | | | IR types. llvm-svn: 202827
* [Modules] Move ValueHandle into the IR library where Value itself lives.Chandler Carruth2014-03-042-2/+2
| | | | | | | | | | | Move the test for this class into the IR unittests as well. This uncovers that ValueMap too is in the IR library. Ironically, the unittest for ValueMap is useless in the Support library (honestly, so was the ValueHandle test) and so it already lives in the IR unittests. Mmmm, tasty layering. llvm-svn: 202821
* [Modules] Move the LLVM IR pattern match header into the IR library, itChandler Carruth2014-03-043-3/+3
| | | | | | obviously is coupled to the IR. llvm-svn: 202818
* [Modules] Move CallSite into the IR library where it belogs. It isChandler Carruth2014-03-048-8/+8
| | | | | | | abstracting between a CallInst and an InvokeInst, both of which are IR concepts. llvm-svn: 202816
* [Modules] Move GetElementPtrTypeIterator into the IR library. As itsChandler Carruth2014-03-046-6/+6
| | | | | | | | | name might indicate, it is an iterator over the types in an instruction in the IR.... You see where this is going. Another step of modularizing the support library. llvm-svn: 202815
* [Modules] Move InstIterator out of the Support library, where it had noChandler Carruth2014-03-048-8/+8
| | | | | | | | | | | | | business. This header includes Function and BasicBlock and directly uses the interfaces of both classes. It has to do with the IR, it even has that in the name. =] Put it in the library it belongs to. This is one step toward making LLVM's Support library survive a C++ modules bootstrap. llvm-svn: 202814
* [cleanup] Re-sort all the includes with utils/sort_includes.py.Chandler Carruth2014-03-043-3/+3
| | | | llvm-svn: 202811
* [C++11] Add a basic block range view for RegionInfoTobias Grosser2014-03-033-9/+7
| | | | | | This also switches the users in LLVM to ensure this functionality is tested. llvm-svn: 202705
* [C++11] Add two range adaptor views to User: operands andChandler Carruth2014-03-031-9/+5
| | | | | | | | | | | | | | | | | | operand_values. The first provides a range view over operand Use objects, and the second provides a range view over the Value*s being used by those operands. The naming is "STL-style" rather than "LLVM-style" because we have historically named iterator methods STL-style, and range methods seem to have far more in common with their iterator counterparts than with "normal" APIs. Feel free to bikeshed on this one if you want, I'm happy to change these around if people feel strongly. I've switched code in SROA and LCG to exercise these mostly to ensure they work correctly -- we don't really have an easy way to unittest this and they're trivial. llvm-svn: 202687
* [C++11] Replace llvm::tie with std::tie.Benjamin Kramer2014-03-022-5/+5
| | | | | | The old implementation is no longer needed in C++11. llvm-svn: 202644
* [C++11] Replace llvm::next and llvm::prior with std::next and std::prev.Benjamin Kramer2014-03-025-9/+9
| | | | | | Remove the old functions. llvm-svn: 202636
* Switch all uses of LLVM_OVERRIDE to just use 'override' directly.Craig Topper2014-03-021-49/+45
| | | | llvm-svn: 202621
* Switch all uses of LLVM_FINAL to just use 'final', and remove the macro.Craig Topper2014-03-021-1/+1
| | | | llvm-svn: 202618
* [C++11] Switch all uses of the llvm_move macro to use std::moveChandler Carruth2014-03-021-1/+1
| | | | | | directly, and remove the macro. llvm-svn: 202612
* [C++11] Remove the use of LLVM_HAS_RVALUE_REFERENCES from the rest ofChandler Carruth2014-03-011-6/+0
| | | | | | the core LLVM libraries. llvm-svn: 202582
* Remove unnecessary llvm:: qualification.Eric Christopher2014-02-261-1/+1
| | | | llvm-svn: 202316
* Constify the Optnone checks in IR passes.Paul Robinson2014-02-261-2/+2
| | | | llvm-svn: 202213
* Use DataLayout from the module when easily available.Rafael Espindola2014-02-251-4/+4
| | | | | | | | | | | | | | | | | Eventually DataLayoutPass should go away, but for now that is the only easy way to get a DataLayout in some APIs. This patch only changes the ones that have easy access to a Module. One interesting issue with sometimes using DataLayoutPass and sometimes fetching it from the Module is that we have to make sure they are equivalent. We can get most of the way there by always constructing the pass with a Module. In fact, the pass could be changed to point to an external DataLayout instead of owning one to make this stricter. Unfortunately, the C api passes a DataLayout, so it has to be up to the caller to make sure the pass and the module are in sync. llvm-svn: 202204
* Make DataLayout a plain object, not a pass.Rafael Espindola2014-02-259-9/+18
| | | | | | | Instead, have a DataLayoutPass that holds one. This will allow parts of LLVM don't don't handle passes to also use DataLayout. llvm-svn: 202168
* Make some DataLayout pointers const.Rafael Espindola2014-02-241-2/+2
| | | | | | No functionality change. Just reduces the noise of an upcoming patch. llvm-svn: 202087
* Replace the F_Binary flag with a F_Text one.Rafael Espindola2014-02-241-2/+2
| | | | | | | | | After this I will set the default back to F_None. The advantage is that before this patch forgetting to set F_Binary would corrupt a file on windows. Forgetting to set F_Text produces one that cannot be read in notepad, which is a better failure mode :-) llvm-svn: 202052
* Don't make F_None the default.Rafael Espindola2014-02-241-2/+2
| | | | | | This will make it easier to switch the default to being binary files. llvm-svn: 202042
* Rename a few more DataLayout variables from TD to DL.Rafael Espindola2014-02-211-21/+21
| | | | llvm-svn: 201870
* fix a corner case in delinearizationSebastian Pop2014-02-211-24/+15
| | | | | | handle special cases Step==1, Step==-1, GCD==1, and GCD==-1 llvm-svn: 201868
* normalize the last delinearized dimensionSebastian Pop2014-02-211-2/+17
| | | | | | | | | | | | | | | | in the dependence test, we used to discard some information that the delinearization provides: the size of the innermost dimension of an array, i.e., the size of scalars stored in the array, and the remainder of the delinearization that provides the offset from which the array reads start, i.e., the base address of the array. To avoid losing this data in the rest of the data dependence analysis, the fix is to multiply the access function in the last delinearized dimension by its size, effectively making the size of the last dimension to always be in bytes, and then add the remainder of delinearization to the last subscript, effectively making the last subscript start at the base address of the array. llvm-svn: 201867
* fail delinearization when the size of subscripts differsSebastian Pop2014-02-211-1/+14
| | | | | | | | | | | Because the delinearization is not a global analysis pass, it will compute the delinearization independently of knowledge about the way the delinearization happened for other data accesses to the same array: the dependence analysis will only trigger the delinearization on a tuple of access functions, and thus delinearization may compute different subscripts sizes for a same array. When that happens the safest is to discard the delinearized information. llvm-svn: 201866
OpenPOWER on IntegriCloud