summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Analysis/IPA
Commit message (Collapse)AuthorAgeFilesLines
* Check the alwaysinline attribute on the call as well as on the caller.Peter Collingbourne2014-05-191-1/+1
| | | | | | Differential Revision: http://reviews.llvm.org/D3815 llvm-svn: 209150
* Add C API for thread yielding callback.Juergen Ributzka2014-05-161-2/+6
| | | | | | | | | | | | | | | | | | | | | Sometimes a LLVM compilation may take more time then a client would like to wait for. The problem is that it is not possible to safely suspend the LLVM thread from the outside. When the timing is bad it might be possible that the LLVM thread holds a global mutex and this would block any progress in any other thread. This commit adds a new yield callback function that can be registered with a context. LLVM will try to yield by calling this callback function, but there is no guaranteed frequency. LLVM will only do so if it can guarantee that suspending the thread won't block any forward progress in other LLVM contexts in the same process. Once the client receives the call back it can suspend the thread safely and resume it at another time. Related to <rdar://problem/16728690> llvm-svn: 208945
* Use a range loop.Rafael Espindola2014-05-081-4/+2
| | | | llvm-svn: 208343
* [inliner] Significantly improve the compile time in cases like PR19499Chandler Carruth2014-04-281-3/+23
| | | | | | | | | | | | | | | by avoiding inlining massive switches merely because they have no instructions in them. These switches still show up where we fail to form lookup tables, and in those cases they are actually going to cause a very significant code size hit anyways, so inlining them is not the right call. The right way to fix any performance regressions stemming from this is to enhance the switch-to-lookup-table logic to fire in more places. This makes PR19499 about 5x less bad. It uncovers a second compile time problem in that test case that is unrelated (surprisingly!). llvm-svn: 207403
* [C++] Use 'nullptr'.Craig Topper2014-04-281-1/+1
| | | | llvm-svn: 207394
* SCC: Change clients to use const, NFCDuncan P. N. Exon Smith2014-04-252-3/+3
| | | | | | | | | | It's fishy to be changing the `std::vector<>` owned by the iterator, and no one actual does it, so I'm going to remove the ability in a subsequent commit. First, update the users. <rdar://problem/14292693> llvm-svn: 207252
* [C++] Use 'nullptr'.Craig Topper2014-04-244-18/+18
| | | | llvm-svn: 207083
* [Modules] Fix potential ODR violations by sinking the DEBUG_TYPEChandler Carruth2014-04-223-3/+6
| | | | | | | | | | definition below all the header #include lines, lib/Analysis/... edition. This one has a bit extra as there were *other* #define's before #include lines in addition to DEBUG_TYPE. I've sunk all of them as a block. llvm-svn: 206843
* remove some dead codeNuno Lopes2014-04-171-18/+0
| | | | | | | | | | | | | | | lib/Analysis/IPA/InlineCost.cpp | 18 ------------------ lib/Analysis/RegionPass.cpp | 1 - lib/Analysis/TypeBasedAliasAnalysis.cpp | 1 - lib/Transforms/Scalar/LoopUnswitch.cpp | 21 --------------------- lib/Transforms/Utils/LCSSA.cpp | 2 -- lib/Transforms/Utils/LoopSimplify.cpp | 6 ------ utils/TableGen/AsmWriterEmitter.cpp | 13 ------------- utils/TableGen/DFAPacketizerEmitter.cpp | 7 ------- utils/TableGen/IntrinsicEmitter.cpp | 2 -- 9 files changed, 71 deletions(-) llvm-svn: 206506
* Reverse 206485.Gerolf Hoflehner2014-04-171-8/+2
| | | | | | | | | After some discussions the preferred semantics of the always_inline attribute is inline always when the compiler can determine that it it safe to do so. llvm-svn: 206487
* Inline a function when the always_inline attributeGerolf Hoflehner2014-04-171-2/+8
| | | | | | | | | | is set even when it contains a indirect branch. The attribute overrules correctness concerns like the escape of a local block address. This is for rdar://16501761 llvm-svn: 206429
* Handle vlas during inline cost computation if they'll be turnedEric Christopher2014-04-071-1/+10
| | | | | | | | | | | into a constant size alloca by inlining. Ran a run over the testsuite, no results out of the noise, fixes the testcase in the PR. PR19115. llvm-svn: 205710
* Consistent use of the noduplicate attribute.Eli Bendersky2014-03-171-1/+1
| | | | | | | | | 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
* [C++11] Add range based accessors for the Use-Def chain of a Value.Chandler Carruth2014-03-092-17/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [Layering] Move InstVisitor.h into the IR library as it is prettyChandler Carruth2014-03-061-1/+1
| | | | | | obviously coupled to the IR. llvm-svn: 203064
* [C++11] Add 'override' keyword to virtual methods that override their base ↵Craig Topper2014-03-052-22/+22
| | | | | | class. llvm-svn: 202945
* [Modules] Move CallSite into the IR library where it belogs. It isChandler Carruth2014-03-042-2/+2
| | | | | | | 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-041-1/+1
| | | | | | | | | 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-042-2/+2
| | | | | | | | | | | | | 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
* [C++11] Replace llvm::tie with std::tie.Benjamin Kramer2014-03-021-4/+4
| | | | | | The old implementation is no longer needed in C++11. llvm-svn: 202644
* Remove unnecessary llvm:: qualification.Eric Christopher2014-02-261-1/+1
| | | | llvm-svn: 202316
* 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-251-1/+2
| | | | | | | 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
* Rename many DataLayout variables from TD to DL.Rafael Espindola2014-02-211-20/+20
| | | | | | | | | I am really sorry for the noise, but the current state where some parts of the code use TD (from the old name: TargetData) and other parts use DL makes it hard to write a patch that changes where those variables come from and how they are passed along. llvm-svn: 201827
* Rename some member variables from TD to DL.Rafael Espindola2014-02-181-3/+3
| | | | | | TargetData was renamed DataLayout back in r165242. llvm-svn: 201581
* GlobalsModRef: Unify and clean up duplicated pointer analysis code.Benjamin Kramer2014-02-101-21/+12
| | | | llvm-svn: 201087
* cleanup: scc_iterator consumers should use isAtEndDuncan P. N. Exon Smith2014-02-041-2/+1
| | | | | | | | | | | | | | No functional change. Updated loops from: for (I = scc_begin(), E = scc_end(); I != E; ++I) to: for (I = scc_begin(); !I.isAtEnd(); ++I) for teh win. llvm-svn: 200789
* [inliner] Skip debug intrinsics even earlier in computing the inlineChandler Carruth2014-02-011-0/+10
| | | | | | | | | | | | | | | | | | | | | | | cost so that they don't impact the vector bonus. Fundamentally, counting unsimplified instructions is just *wrong*; it will continue to introduce instability as things which do not generate code bizarrely impact inlining. For example, sufficiently nested inlined functions could turn off the vector bonus with lifetime markers just like the debug intrinsics do. =/ This is a short-term tactical fix. Long term, I think we need to remove the vector bonus entirely. That's a separate patch and discussion though. The patch to fix this provided by Dario Domizioli. I've added some comments about the planned direction and used a heavily pruned form of debug info intrinsics for the test case. While this debug info doesn't work or "do" anything useful, it lets us easily test all manner of interference easily, and I suspect this will not be the last time we want to craft a pattern where debug info interferes with the inliner in a problematic way. llvm-svn: 200609
* [inliner] Print out extra stats about the cost, threshold, and vectorChandler Carruth2014-01-311-0/+3
| | | | | | | | bonus in the inline cost analysis. Split out of a patch by Dario Domizioli to commit separately. llvm-svn: 200586
* Put the functionality for printing a value to a raw_ostream as anChandler Carruth2014-01-091-1/+0
| | | | | | | | | | | | operand into the Value interface just like the core print method is. That gives a more conistent organization to the IR printing interfaces -- they are all attached to the IR objects themselves. Also, update all the users. This removes the 'Writer.h' header which contained only a single function declaration. llvm-svn: 198836
* Move the LLVM IR asm writer header files into the IR directory, as theyChandler Carruth2014-01-071-1/+1
| | | | | | | | | | | | | | | | | 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
* Re-sort all of the includes with ./utils/sort_includes.py so thatChandler Carruth2014-01-071-1/+1
| | | | | | | | | | subsequent changes are easier to review. About to fix some layering issues, and wanted to separate out the necessary churn. Also comment and sink the include of "Windows.h" in three .inc files to match the usage in Memory.inc. llvm-svn: 198685
* [PM] Add a definition for the static PassID in the CallGraphAnalysis.Chandler Carruth2014-01-051-0/+6
| | | | | | | Missed this when adding the skeleton analysis. Caught by a build break in the next patch I'm working on when trying to use the analysis. llvm-svn: 198556
* [inliner] Fix PR18206 by preventing inlining functions that call setjmpChandler Carruth2013-12-131-1/+1
| | | | | | | | | | | | | through an invoke instruction. The original patch for this was written by Mark Seaborn, but I've reworked his test case into the existing returns_twice test case and implemented the fix by the prior refactoring to actually run the cost analysis over invoke instructions, and then here fixing our detection of the returns_twice attribute to work for both calls and invokes. We never noticed because we never saw an invoke. =[ llvm-svn: 197216
* [inliner] Completely change (and fix) how the inline cost analysisChandler Carruth2013-12-131-37/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | handles terminator instructions. The inline cost analysis inheritted some pretty rough handling of terminator insts from the original cost analysis, and then made it much, much worse by factoring all of the important analyses into a separate instruction visitor. That instruction visitor never visited the terminator. This works fine for things like conditional branches, but for many other things we simply computed The Wrong Value. First example are unconditional branches, which should be free but were counted as full cost. This is most significant for conditional branches where the condition simplifies and folds during inlining. We paid a 1 instruction tax on every branch in a straight line specialized path. =[ Oh, we also claimed that the unreachable instruction had cost. But it gets worse. Let's consider invoke. We never applied the call penalty. We never accounted for the cost of the arguments. Nope. Worse still, we didn't handle the *correctness* constraints of not inlining recursive invokes, or exception throwing returns_twice functions. Oops. See PR18206. Sadly, PR18206 requires yet another fix, but this refactoring is at least a huge step in that direction. llvm-svn: 197215
* [cleanup] Remove trailing whitespace before I start changing this file.Chandler Carruth2013-12-121-1/+1
| | | | llvm-svn: 197149
* [PM] Split the CallGraph out from the ModulePass which creates theChandler Carruth2013-11-265-81/+116
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] Reformat some code with clang-format as I'm going to be editting asChandler Carruth2013-11-261-21/+12
| | | | | | | part of generalizing the call graph infrastructure for the new pass manager. llvm-svn: 195718
* [PM] Rename the 'Mod' member to the more idiomatic 'M'. No functionalityChandler Carruth2013-11-261-3/+3
| | | | | | changed. llvm-svn: 195701
* The 'optnone' attribute means don't inline anything into this functionPaul Robinson2013-11-181-0/+4
| | | | | | | | | | (except functions marked always_inline). Functions with 'optnone' must also have 'noinline' so they don't get inlined into any other function. Based on work by Andrea Di Biagio. llvm-svn: 195046
* Move the old pass manager infrastructure into a legacy namespace andChandler Carruth2013-11-091-1/+1
| | | | | | | | | | | | | | | | | | | give the files a legacy prefix in the right directory. Use forwarding headers in the old locations to paper over the name change for most clients during the transitional period. No functionality changed here! This is just clearing some space to reduce renaming churn later on with a new system. Even when the new stuff starts to go in, it is going to be hidden behind a flag and off-by-default as it is still WIP and under development. This patch is specifically designed so that very little out-of-tree code has to change. I'm going to work as hard as I can to keep that the case. Only direct forward declarations of the PassManager class are impacted by this change. llvm-svn: 194324
* Merge CallGraph and BasicCallGraph.Rafael Espindola2013-10-313-159/+80
| | | | llvm-svn: 193734
* Call destroy from ~BasicCallGraph.Rafael Espindola2013-10-251-0/+4
| | | | | | | | | | | | This fix a memory leak found by valgrind. Calling it from the base class destructor would not destroy the BasicCallGraph bits. FIXME: BasicCallGraph is the only thing that inherits from CallGraph. Can we merge the two? llvm-svn: 193412
* Disable inlining between sanitized and non-sanitized functions.Evgeniy Stepanov2013-08-081-5/+23
| | | | | | | Inlining between functions with different values of sanitize_* attributes leads to over- or under-sanitizing, which is always bad. llvm-svn: 187967
* Have InlineCost check constant fcmpsMatt Arsenault2013-07-201-4/+8
| | | | llvm-svn: 186758
* This patch breaks up Wrap.h so that it does not have to include all of Filip Pizlo2013-05-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | the things, and renames it to CBindingWrapping.h. I also moved CBindingWrapping.h into Support/. This new file just contains the macros for defining different wrap/unwrap methods. The calls to those macros, as well as any custom wrap/unwrap definitions (like for array of Values for example), are put into corresponding C++ headers. Doing this required some #include surgery, since some .cpp files relied on the fact that including Wrap.h implicitly caused the inclusion of a bunch of other things. This also now means that the C++ headers will include their corresponding C API headers; for example Value.h must include llvm-c/Core.h. I think this is harmless, since the C API headers contain just external function declarations and some C types, so I don't believe there should be any nasty dependency issues here. llvm-svn: 180881
* Move C++ code out of the C headers and into either C++ headersEric Christopher2013-04-221-0/+1
| | | | | | | or the C++ files themselves. This enables people to use just a C compiler to interoperate with LLVM. llvm-svn: 180063
* ArrayRef ca accept one element. Simplify code a little bit, also it matches nowJakub Staszak2013-03-071-3/+5
| | | | | | coding in the other places of the file. llvm-svn: 176641
* Begin fleshing out an interface in TTI for modelling the costs ofChandler Carruth2013-01-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | generic function calls and intrinsics. This is somewhat overlapping with an existing intrinsic cost method, but that one seems targetted at vector intrinsics. I'll merge them or separate their names and use cases in a separate commit. This sinks the test of 'callIsSmall' down into TTI where targets can control it. The whole thing feels very hack-ish to me though. I've left a FIXME comment about the fundamental design problem this presents. It isn't yet clear to me what the users of this function *really* care about. I'll have to do more analysis to figure that out. Putting this here at least provides it access to proper analysis pass tools and other such. It also allows us to more cleanly implement the baseline cost interfaces in TTI. With this commit, it is now theoretically possible to simplify much of the inline cost analysis's handling of calls by calling through to this interface. That conversion will have to happen in subsequent commits as it requires more extensive restructuring of the inline cost analysis. The CodeMetrics class is now really only in the business of running over a block of code and aggregating the metrics on that block of code, with the actual cost evaluation done entirely in terms of TTI. llvm-svn: 173148
* Sink InlineCost.cpp into IPA -- it is now officially an interproceduralChandler Carruth2013-01-212-0/+1238
| | | | | | | | | | analysis. How cute that it wasn't previously. ;] Part of this confusion stems from the flattened header file tree. Thanks to Benjamin for pointing out the goof on IRC, and we're considering un-flattening the headers, so speak now if that would bug you. llvm-svn: 173033
OpenPOWER on IntegriCloud