summaryrefslogtreecommitdiffstats
path: root/llvm/unittests/IR
Commit message (Collapse)AuthorAgeFilesLines
...
* SmallVector<3> may be used here.NAKAMURA Takumi2014-03-271-1/+1
| | | | llvm-svn: 204915
* IRTests/InstructionsTest.cpp: Avoid initializer list.NAKAMURA Takumi2014-03-271-4/+4
| | | | llvm-svn: 204914
* Add a unit test for Invoke iteration, similar to the one for CallEli Bendersky2014-03-261-11/+40
| | | | | | The tests are refactored to use the same fixture. llvm-svn: 204860
* Fix bot breakage in InstructionsTest.Eli Bendersky2014-03-261-1/+1
| | | | | | Makes sure the Call dies before the Function llvm-svn: 204856
* Fix problem with r204836Eli Bendersky2014-03-261-0/+26
| | | | | | | | | | In CallInst, op_end() points at the callee, which we don't want to iterate over when just iterating over arguments. Now take this into account when returning a iterator_range from arg_operands. Similar reasoning for InvokeInst. Also adds a unit test to verify this actually works as expected. llvm-svn: 204851
* [PM] As was pointed out in review, I need to define a custom swap inChandler Carruth2014-03-131-3/+44
| | | | | | | | | | | | | order to use the single assignment. That's probably worth doing for a lot of these types anyways as they may have non-trivial moves and so getting copy elision in more places seems worthwhile. I've tried to add some tests that actually catch this mistake, and one of the types is now well tested but the others' tests still fail to catch this. I'll keep working on tests, but this gets the core pattern right. llvm-svn: 203780
* [PM] While I'm here, fix a few other clang-format issues. Pulls someChandler Carruth2014-03-101-4/+2
| | | | | | lines under 80-columns, etc. llvm-svn: 203434
* [PM] Switch new pass manager from polymorphic_ptr to unique_ptr now thatChandler Carruth2014-03-091-23/+33
| | | | | | | it is available. Also make the move semantics sufficiently correct to tolerate move-only passes, as the PassManagers *are* move-only passes. llvm-svn: 203391
* [C++11] Now that the users are gone, rip out the duplicated traits from ↵Benjamin Kramer2014-03-071-1/+2
| | | | | | | | type_traits.h Simplify the remaining ones a bit. llvm-svn: 203249
* Replace OwningPtr<T> with std::unique_ptr<T>.Ahmed Charles2014-03-0610-15/+11
| | | | | | | | | | 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
* [Modules] Move the LeakDetector header into the IR library where theChandler Carruth2014-03-042-0/+32
| | | | | | | | | | | source file had already been moved. Also move the unittest into the IR unittest library. This may seem an odd thing to put in the IR library but we only really use this with instructions and it needs the LLVM context to work, so it is intrinsically tied to the IR library. llvm-svn: 202842
* [Modules] Move the ConstantRange class into the IR library. This isChandler Carruth2014-03-042-0/+513
| | | | | | | | | | 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 NoFolder into the IR library as it createsChandler Carruth2014-03-042-2/+2
| | | | | | instructions. llvm-svn: 202834
* [Modules] Move ValueMap to the IR library. While this class does notChandler Carruth2014-03-041-1/+1
| | | | | | | | | | | | directly care about the Value class (it is templated so that the key can be any arbitrary Value subclass), it is in fact concretely tied to the Value class through the ValueHandle's CallbackVH interface which relies on the key type being some Value subclass to establish the value handle chain. Ironically, the unittest is already in the right library. llvm-svn: 202824
* [Modules] Move ValueHandle into the IR library where Value itself lives.Chandler Carruth2014-03-043-1/+410
| | | | | | | | | | | 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-041-1/+1
| | | | | | obviously is coupled to the IR. llvm-svn: 202818
* Cleaning up a bunch of pre-Visual C++ 2012 build hacks.Yaron Keren2014-03-041-6/+0
| | | | llvm-svn: 202806
* [C++11] Replace LLVM_STATIC_ASSERT with static_assert, we now haveChandler Carruth2014-03-021-2/+1
| | | | | | access to it on all host toolchains. llvm-svn: 202642
* [C++11] Replace llvm::next and llvm::prior with std::next and std::prev.Benjamin Kramer2014-03-021-2/+2
| | | | | | Remove the old functions. llvm-svn: 202636
* Fix resetting the DataLayout in a Module.Rafael Espindola2014-02-251-0/+8
| | | | | | | | | | | | | | | No tool does this currently, but as everything else in a module we should be able to change its DataLayout. Most of the fix is in DataLayout to make sure it can be reset properly. The test uses Module::setDataLayout since the fact that we mutate a DataLayout is an implementation detail. The module could hold a OwningPtr<DataLayout> and the DataLayout itself could be immutable. Thanks to Philip Reames for pushing me in the right direction. llvm-svn: 202198
* Make DataLayout a plain object, not a pass.Rafael Espindola2014-02-251-10/+10
| | | | | | | 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
* [PM] Don't require analysis results to be const in the new pass manager.Chandler Carruth2014-02-051-3/+3
| | | | | | | | | | I think this was just over-eagerness on my part. The analysis results need to often be non-const because they need to (in some cases at least) be updated by the transformation pass in order to remain correct. It also makes lazy analyses (a common case) needlessly annoying to write in order to make their entire state mutable. llvm-svn: 200881
* Bug 18228 - Fix accepting bitcasts between vectors of pointers with aMatt Arsenault2014-01-221-0/+16
| | | | | | | | | | | | | different number of elements. Bitcasts were passing with vectors of pointers with different number of elements since the number of elements was checking SrcTy->getVectorNumElements() == SrcTy->getVectorNumElements() which isn't helpful. The addrspacecast was also wrong, but that case at least is caught by the verifier. Refactor bitcast and addrspacecast handling in castIsValid to be more readable and fix this problem. llvm-svn: 199821
* [PM] Make the verifier work independently of any pass manager.Chandler Carruth2014-01-191-6/+9
| | | | | | | | | | | | | | | | | | | | | | | This makes the 'verifyFunction' and 'verifyModule' functions totally independent operations on the LLVM IR. It also cleans up their API a bit by lifting the abort behavior into their clients and just using an optional raw_ostream parameter to control printing. The implementation of the verifier is now just an InstVisitor with no multiple inheritance. It also is significantly more const-correct, and hides the const violations internally. The two layers that force us to break const correctness are building a DomTree and dispatching through the InstVisitor. A new VerifierPass is used to implement the legacy pass manager interface in terms of the other pieces. The error messages produced may be slightly different now, and we may have slightly different short circuiting behavior with different usage models of the verifier, but generally everything works equivalently and this unblocks wiring the verifier up to the new pass manager. llvm-svn: 199569
* [PM] Split DominatorTree into a concrete analysis result object whichChandler Carruth2014-01-131-3/+4
| | | | | | | | | | | | | | | | | | | | | | | can be used by both the new pass manager and the old. This removes it from any of the virtual mess of the pass interfaces and lets it derive cleanly from the DominatorTreeBase<> template. In turn, tons of boilerplate interface can be nuked and it turns into a very straightforward extension of the base DominatorTree interface. The old analysis pass is now a simple wrapper. The names and style of this split should match the split between CallGraph and CallGraphWrapperPass. All of the users of DominatorTree have been updated to match using many of the same tricks as with CallGraph. The goal is that the common type remains the resulting DominatorTree rather than the pass. This will make subsequent work toward the new pass manager significantly easier. Also in numerous places things became cleaner because I switched from re-running the pass (!!! mid way through some other passes run!!!) to directly recomputing the domtree. llvm-svn: 199104
* [cleanup] Move the Dominators.h and Verifier.h headers into the IRChandler Carruth2014-01-133-3/+3
| | | | | | | | | | | | | | | | | | directory. These passes are already defined in the IR library, and it doesn't make any sense to have the headers in Analysis. Long term, I think there is going to be a much better way to divide these matters. The dominators code should be fully separated into the abstract graph algorithm and have that put in Support where it becomes obvious that evn Clang's CFGBlock's can use it. Then the verifier can manually construct dominance information from the Support-driven interface while the Analysis library can provide a pass which both caches, reconstructs, and supports a nice update API. But those are very long term, and so I don't want to leave the really confusing structure until that day arrives. llvm-svn: 199082
* [PM] Rename the IR printing pass header to a more generic and correctChandler Carruth2014-01-121-1/+1
| | | | | | | | name to match the source file which I got earlier. Update the include sites. Also modernize the comments in the header to use the more recommended doxygen style. llvm-svn: 199041
* [PM] Add names to passes under the new pass manager, and a debug outputChandler Carruth2014-01-111-0/+10
| | | | | | | | | | mode that can be used to debug the execution of everything. No support for analyses here, that will come later. This already helps show parts of the opt commandline integration that isn't working. Tests of that will start using it as the bugs are fixed. llvm-svn: 199004
* Move the LLVM IR asm writer header files into the IR directory, as theyChandler Carruth2014-01-074-4/+4
| | | | | | | | | | | | | | | | | are part of the core IR library in order to support dumping and other basic functionality. Rename the 'Assembly' include directory to 'AsmParser' to match the library name and the only functionality left their -- printing has been in the core IR library for quite some time. Update all of the #includes to match. All of this started because I wanted to have the layering in good shape before I started adding support for printing LLVM IR using the new pass infrastructure, and commandline support for the new pass infrastructure. llvm-svn: 198688
* Add in a unittest for the one-use pattern matcher.Chandler Carruth2014-01-051-0/+20
| | | | llvm-svn: 198552
* Add support to the pattern match library for matching NSW and NUWChandler Carruth2014-01-051-0/+74
| | | | | | | | | | | instructions. I needed this for a quick experiment I was making, and while I've no idea if that will ever get committed, I didn't want to throw away the pattern match code and for anyone else to have to write it again. I've added unittests to make sure this works correctly. In fun news, this also uncovered the IRBuilder bug. Doh! llvm-svn: 198541
* Fix a bug in IRBuilder that's been there for who knows how long. ItChandler Carruth2014-01-051-0/+51
| | | | | | | | failed to correctly propagate the NUW and NSW flags to the constant folder for two instructions. I've added a unittest to cover flag propagation for the rest of the instructions and constant expressions. llvm-svn: 198538
* Use a shorter name for the IRBuilder member. This will help the testsChandler Carruth2014-01-051-54/+54
| | | | | | I'm adding next be a lot more readable. llvm-svn: 198534
* Simplify the PatternMatch unittest by giving it a module, function, andChandler Carruth2014-01-051-166/+105
| | | | | | | | | basic block to hold instructions, and managing all of their lifetimes in a fixture. This makes it easy to sink the expectations into the test cases themselves which also makes things a bit more explicit and clearer IMO. llvm-svn: 198532
* Use LLVM_STATIC_ASSERT rather than a hand-rolled implementation.David Blaikie2014-01-021-2/+2
| | | | llvm-svn: 198330
* Rename 'assert' to something less loaded in CompileAssertHasTypeAlp Toker2014-01-011-1/+1
| | | | | | Suggested by Aaron Ballman. llvm-svn: 198288
* Silence g++ 4.9 build issue in unit testsAlp Toker2014-01-011-1/+2
| | | | | | Stopgap measure until we can just use static_assert(). llvm-svn: 198273
* Use a: and s: instead of a0: and s0: in the DataLayout strings.Rafael Espindola2013-12-132-3/+3
| | | | | | They are equivalent and the size of 'a' and 's' is unused. llvm-svn: 197259
* [CMake] Update LLVM_LINK_COMPONENTS for each CMakeLists.txt.NAKAMURA Takumi2013-12-101-3/+5
| | | | llvm-svn: 196908
* Use present fast-math flags when applicable in CreateBinOpMichael Ilseman2013-12-051-0/+7
| | | | | | | | We were previously not adding fast-math flags through CreateBinOp() when it happened to be making a floating point binary operator. This patch updates it to do so similarly to directly calling CreateF*(). llvm-svn: 196438
* Fix dominator descendants for unreachable blocks.Diego Novillo2013-12-021-0/+27
| | | | | | | | | | | | | When a block is unreachable, asking its dom tree descendants should return the empty set. However, the computation of the descendants was causing a segmentation fault because the dom tree node we get from the basic block is initially NULL. Fixed by adding a test for a valid dom tree node before we iterate. The patch also adds some unit tests to the existing dom tree tests. llvm-svn: 196099
* [PM] Split the CallGraph out from the ModulePass which creates theChandler Carruth2013-11-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CallGraph. This makes the CallGraph a totally generic analysis object that is the container for the graph data structure and the primary interface for querying and manipulating it. The pass logic is separated into its own class. For compatibility reasons, the pass provides wrapper methods for most of the methods on CallGraph -- they all just forward. This will allow the new pass manager infrastructure to provide its own analysis pass that constructs the same CallGraph object and makes it available. The idea is that in the new pass manager, the analysis pass's 'run' method returns a concrete analysis 'result'. Here, that result is a 'CallGraph'. The 'run' method will typically do only minimal work, deferring much of the work into the implementation of the result object in order to be lazy about computing things, but when (like DomTree) there is *some* up-front computation, the analysis does it prior to handing the result back to the querying pass. I know some of this is fairly ugly. I'm happy to change it around if folks can suggest a cleaner interim state, but there is going to be some amount of unavoidable ugliness during the transition period. The good thing is that this is very limited and will naturally go away when the old pass infrastructure goes away. It won't hang around to bother us later. Next up is the initial new-PM-style call graph analysis. =] llvm-svn: 195722
* [PM] Complete the cross-layer interfaces with a Module-to-FunctionChandler Carruth2013-11-231-12/+65
| | | | | | | | | | | | | proxy. This lets a function pass query a module analysis manager. However, the interface is const to indicate that only cached results can be safely queried. With this, I think the new pass manager is largely functionally complete for modules and analyses. Still lots to test, and need to generalize to SCCs and Loops, and need to build an adaptor layer to support the use of existing Pass objects in the new managers. llvm-svn: 195538
* [PM] Rename TestAnalysisPass to TestFunctionAnalysis to clear the wayChandler Carruth2013-11-231-7/+7
| | | | | | for a TestModuleAnalysis. llvm-svn: 195537
* [PM] Add support to the analysis managers to query explicitly for cachedChandler Carruth2013-11-231-5/+34
| | | | | | | | | | | results. This is the last piece of infrastructure needed to effectively support querying *up* the analysis layers. The next step will be to introduce a proxy which provides access to those layers with appropriate use of const to direct queries to the safe interface. llvm-svn: 195525
* [PM] Switch the downward invalidation to be incremental where only theChandler Carruth2013-11-221-4/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | one function's analyses are invalidated at a time. Also switch the preservation of the proxy to *fully* preserve the lower (function) analyses. Combined, this gets both upward and downward analysis invalidation to a point I'm happy with: - A function pass invalidates its function analyses, and its parent's module analyses. - A module pass invalidates all of its functions' analyses including the set of which functions are in the module. - A function pass can preserve a module analysis pass. - If all function passes preserve a module analysis pass, that preservation persists. If any doesn't the module analysis is invalidated. - A module pass can opt into managing *all* function analysis invalidation itself or *none*. - The conservative default is none, and the proxy takes the maximally conservative approach that works even if the set of functions has changed. - If a module pass opts into managing function analysis invalidation it has to propagate the invalidation itself, the proxy just does nothing. The only thing really missing is a way to query for a cached analysis or nothing at all. With this, function passes can more safely request a cached module analysis pass without fear of it accidentally running part way through. llvm-svn: 195519
* [PM] Teach the analysis managers to pass themselves as arguments to theChandler Carruth2013-11-221-1/+1
| | | | | | | | | | | | | | run methods of the analysis passes. Also generalizes and re-uses the SFINAE for transformation passes so that users can write an analysis pass and only accept an analysis manager if that is useful to their pass. This completes the plumbing to make an analysis manager available through every pass's run method if desired so that passes no longer need to be constructed around them. llvm-svn: 195451
* [PM] Remove the IRUnitT typedef requirement for analysis passes.Chandler Carruth2013-11-221-2/+0
| | | | | | | | | | | | Since the analysis managers were split into explicit function and module analysis managers, it is now completely trivial to specify this when building up the concept and model types explicitly, and it is impossible to end up with a type error at run time. We instantiate a template when registering a pass that will enforce the requirement at a type-system level, and we produce a dynamic error on all the other query paths to the analysis manager if the pass in question isn't registered. llvm-svn: 195447
* [PM] Fix the analysis templates' usage of IRUnitT.Chandler Carruth2013-11-221-1/+1
| | | | | | | | | | | This is supposed to be the whole type of the IR unit, and so we shouldn't pass a pointer to it but rather the value itself. In turn, we need to provide a 'Module *' as that type argument (for example). This will become more relevant with SCCs or other units which may not be passed as a pointer type, but also brings consistency with the transformation pass templates. llvm-svn: 195445
* [PM] Switch analysis managers to be threaded through the run methodsChandler Carruth2013-11-221-22/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | rather than the constructors of passes. This simplifies the APIs of passes significantly and removes an error prone pattern where the *same* manager had to be given to every different layer. With the new API the analysis managers themselves will have to be cross connected with proxy analyses that allow a pass at one layer to query for the analysis manager of another layer. The proxy will both expose a handle to the other layer's manager and it will provide the invalidation hooks to ensure things remain consistent across layers. Finally, the outer-most analysis manager has to be passed to the run method of the outer-most pass manager. The rest of the propagation is automatic. I've used SFINAE again to allow passes to completely disregard the analysis manager if they don't need or want to care. This helps keep simple things simple for users of the new pass manager. Also, the system specifically supports passing a null pointer into the outer-most run method if your pass pipeline neither needs nor wants to deal with analyses. I find this of dubious utility as while some *passes* don't care about analysis, I'm not sure there are any real-world users of the pass manager itself that need to avoid even creating an analysis manager. But it is easy to support, so there we go. Finally I renamed the module proxy for the function analysis manager to the more verbose but less confusing name of FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea what else to name these things. I'm expecting in the fullness of time to potentially have the complete cross product of types at the proxy layer: {Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy (except for XAnalysisManagerXProxy which doesn't make any sense) This should make it somewhat easier to do the next phases which is to build the upward proxy and get its invalidation correct, as well as to make the invalidation within the Module -> Function mapping pass be more fine grained so as to invalidate fewer fuction analyses. After all of the proxy analyses are done and the invalidation working, I'll finally be able to start working on the next two fun fronts: how to adapt an existing pass to work in both the legacy pass world and the new one, and building the SCC, Loop, and Region counterparts. Fun times! llvm-svn: 195400
OpenPOWER on IntegriCloud