summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/IPO/ArgumentPromotion.cpp
Commit message (Collapse)AuthorAgeFilesLines
* DebugInfo+DeadArgElimination: Ensure llvm::Function*s from debug info are ↵David Blaikie2014-10-071-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | updated even when DAE removes both varargs and non-varargs arguments on the same function. After some stellar (& inspired) help from Reid Kleckner providing a test case for some rather unstable undefined behavior showing up as assertions produced by r214761, I was able to fix this issue in DAE involving the application of both varargs removal, followed by normal argument removal. Indeed I introduced this same bug into ArgumentPromotion (r212128) by copying the code from DAE, and when I fixed the bug in ArgPromo (r213805) and commented in that patch that I didn't need to address the same issue in DAE because it was a single pass. Turns out it's two pass, one for the varargs and one for the normal arguments, so the same fix is needed (at least during varargs removal). So here it is. (the observable/net effect of this bug, even when it didn't result in assertion failure, is that debug info would describe the DAE'd function in the abstract, but wouldn't provide high/low_pc, variable locations, line table, etc (it would appear as though the function had been entirely optimized away), see the original PR14016 for details of the general problem) I'm not recommitting the assertion just yet, as there's been another regression of it since I last tried. It might just be a few test cases weren't adequately updated after Adrian or Duncan's recent schema changes. llvm-svn: 219210
* Eliminate some deep std::vector copies. NFC.Benjamin Kramer2014-10-031-1/+1
| | | | llvm-svn: 218999
* Don't promote byval pointer arguments when padding mattersReid Kleckner2014-08-281-3/+81
| | | | | | | | | | | | | | | | Don't promote byval pointer arguments when when their size in bits is not equal to their alloc size in bits. This can happen for x86_fp80, where the size in bits is 80 but the alloca size in bits in 128. Promoting these types can break passing unions of x86_fp80s and other types. Patch by Thomas Jablin! Reviewed By: rnk Differential Revision: http://reviews.llvm.org/D5057 llvm-svn: 216693
* ArgPromotion: Don't touch variadic functionsReid Kleckner2014-08-251-0/+7
| | | | | | | | | | | | | | | | Adding, removing, or changing non-pack parameters can change the ABI classification of pack parameters. Clang and other frontends encode the classification in the IR of the call site, but the callee side determines it dynamically based on the number of registers consumed so far. Changing the prototype affects the number of registers consumed would break such code. Dead argument elimination performs a similar task and already has a similar check to avoid this problem. Patch by Thomas Jablin! llvm-svn: 216421
* Use range based for loops to avoid needing to re-mention SmallPtrSet size.Craig Topper2014-08-241-4/+2
| | | | llvm-svn: 216351
* Repace SmallPtrSet with SmallPtrSetImpl in function arguments to avoid ↵Craig Topper2014-08-211-4/+4
| | | | | | needing to mention the size. llvm-svn: 216158
* Revert "Repace SmallPtrSet with SmallPtrSetImpl in function arguments to ↵Craig Topper2014-08-181-4/+4
| | | | | | | | avoid needing to mention the size." Getting a weird buildbot failure that I need to investigate. llvm-svn: 215870
* Repace SmallPtrSet with SmallPtrSetImpl in function arguments to avoid ↵Craig Topper2014-08-171-4/+4
| | | | | | needing to mention the size. llvm-svn: 215868
* Fixing a few -Woverloaded-virtual warnings by exposing the hidden virtual ↵Aaron Ballman2014-07-301-0/+2
| | | | | | function as well. No functional changes intended. llvm-svn: 214325
* AA metadata refactoring (introduce AAMDNodes)Hal Finkel2014-07-241-3/+5
| | | | | | | | | | | | | | | | | | | | In order to enable the preservation of noalias function parameter information after inlining, and the representation of block-level __restrict__ pointer information (etc.), additional kinds of aliasing metadata will be introduced. This metadata needs to be carried around in AliasAnalysis::Location objects (and MMOs at the SDAG level), and so we need to generalize the current scheme (which is hard-coded to just one TBAA MDNode*). This commit introduces only the necessary refactoring to allow for the introduction of other aliasing metadata types, but does not actually introduce any (that will come in a follow-up commit). What it does introduce is a new AAMDNodes structure to hold all of the aliasing metadata nodes associated with a particular memory-accessing instruction, and uses that structure instead of the raw MDNode* in AliasAnalysis::Location, etc. No functionality change intended. llvm-svn: 213859
* ArgPromo+DebugInfo: Handle updating debug info over multiple applications of ↵David Blaikie2014-07-231-3/+7
| | | | | | | | | | | | | | | | | | | | | | argument promotion. While the subprogram map cache used by Dead Argument Elimination works there, I made a mistake when reusing it for Argument Promotion in r212128 because ArgPromo may transform functions more than once whereas DAE transforms each function only once, removing all the dead arguments in one go. To address this, ensure that the map is updated after each argument promotion. In retrospect it might be a little wasteful to create a map of all subprograms when only handling a single CGSCC, but the alternative is walking the debug info for each function in the CGSCC that gets updated. It's not clear to me what the right tradeoff is there, but since the current tradeoff seems to be working OK (and the code to keep things updated is very cheap), let's stick with that for now. llvm-svn: 213805
* Revert "[C++11] Add predecessors(BasicBlock *) / successors(BasicBlock *) ↵Duncan P. N. Exon Smith2014-07-211-1/+2
| | | | | | | | | iterator ranges." This reverts commit r213474 (and r213475), which causes a miscompile on a stage2 LTO build. I'll reply on the list in a moment. llvm-svn: 213562
* [C++11] Add predecessors(BasicBlock *) / successors(BasicBlock *) iterator ↵Manuel Jacob2014-07-201-2/+1
| | | | | | | | | | | | | | | | | | ranges. Summary: This patch introduces two new iterator ranges and updates existing code to use it. No functional change intended. Test Plan: All tests (make check-all) still pass. Reviewers: dblaikie Reviewed By: dblaikie Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D4481 llvm-svn: 213474
* Allow isDereferenceablePointer to look through some bitcastsHal Finkel2014-07-101-4/+10
| | | | | | | | | | | | | | | | isDereferenceablePointer should not give up upon encountering any bitcast. If we're casting from a pointer to a larger type to a pointer to a small type, we can continue by examining the bitcast's operand. This missing capability was noted in a comment in the function. In order for this to work, isDereferenceablePointer now takes an optional DataLayout pointer (essentially all callers already had such a pointer available). Most code uses isDereferenceablePointer though isSafeToSpeculativelyExecute (which already took an optional DataLayout pointer), and to enable the LICM test case, LICM needs to actually provide its DL pointer to isSafeToSpeculativelyExecute (which it was not doing previously). llvm-svn: 212686
* Constify the Function pointers in the result of makeSubprogramMapDavid Blaikie2014-07-021-1/+1
| | | | | | | These don't need to be mutable and callers being added soon in CodeGen won't have access to non-const Module&. llvm-svn: 212202
* DebugInfo: Keep track of subprograms who's arguments have been promoted.David Blaikie2014-07-011-0/+12
| | | | | | | | | | | | Matching behavior with DeadArgumentElimination (and leveraging some now-common infrastructure), keep track of the function from debug info metadata if arguments are promoted. This may produce interesting debug info - since the arguments may be missing or of different types... but at least backtraces, inlining, etc, will be correct. llvm-svn: 212128
* ArgumentPromotion: Propagate debug locations on calls for which arguments ↵David Blaikie2014-06-271-0/+1
| | | | | | are promoted. llvm-svn: 211872
* [C++] Use 'nullptr'. Transforms edition.Craig Topper2014-04-251-7/+7
| | | | llvm-svn: 207196
* [Modules] Fix potential ODR violations by sinking the DEBUG_TYPEChandler Carruth2014-04-221-1/+2
| | | | | | | | | | | | | | | | | definition below all of the header #include lines, lib/Transforms/... edition. This one is tricky for two reasons. We again have a couple of passes that define something else before the includes as well. I've sunk their name macros with the DEBUG_TYPE. Also, InstCombine contains headers that need DEBUG_TYPE, so now those headers #define and #undef DEBUG_TYPE around their code, leaving them well formed modular headers. Fixing these headers was a large motivation for all of these changes, as "leaky" macros of this form are hard on the modules implementation. llvm-svn: 206844
* [C++11] Add range based accessors for the Use-Def chain of a Value.Chandler Carruth2014-03-091-30/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] Add 'override' keyword to virtual methods that override their base ↵Craig Topper2014-03-051-2/+2
| | | | | | class. llvm-svn: 202953
* [Modules] Move CFG.h to the IR library as it defines graph traits overChandler Carruth2014-03-041-1/+1
| | | | | | IR types. llvm-svn: 202827
* [Modules] Move CallSite into the IR library where it belogs. It isChandler Carruth2014-03-041-1/+1
| | | | | | | abstracting between a CallInst and an InvokeInst, both of which are IR concepts. llvm-svn: 202816
* Update optimization passes to handle inalloca argumentsReid Kleckner2014-01-281-5/+10
| | | | | | | | | | | | | | | Summary: I searched Transforms/ and Analysis/ for 'ByVal' and updated those call sites to check for inalloca if appropriate. I added tests for any change that would allow an optimization to fire on inalloca. Reviewers: nlewycky Differential Revision: http://llvm-reviews.chandlerc.com/D2449 llvm-svn: 200281
* Remove tail marker when changing an argument to an alloca.Rafael Espindola2014-01-231-0/+10
| | | | | | | | | | Argument promotion can replace an argument of a call with an alloca. This requires clearing the tail marker as it is very likely that the callee is now using an alloca in the caller. This fixes pr14710. llvm-svn: 199909
* [PM] Split the CallGraph out from the ModulePass which creates theChandler Carruth2013-11-261-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* ArgumentPromotion: correctly transfer TBAA tags and alignments.Manman Ren2013-11-151-3/+5
| | | | | | | | | | | | | | We used to use std::map<IndicesVector, LoadInst*> for OriginalLoads, and when we try to promote two arguments, they will both write to OriginalLoads causing created loads for the two arguments to have the same original load. And the same tbaa tag and alignment will be put to the created loads for the two arguments. The fix is to use std::map<std::pair<Argument*, IndicesVector>, LoadInst*> for OriginalLoads, so each Argument will write to different parts of the map. PR17906 llvm-svn: 194846
* Merge CallGraph and BasicCallGraph.Rafael Espindola2013-10-311-1/+1
| | | | llvm-svn: 193734
* Clean up some of this code a tiny bit, no functionality change.Nick Lewycky2013-07-181-13/+8
| | | | llvm-svn: 186622
* Use the AttributeSet instead of AttributeWithIndex.Bill Wendling2013-01-271-22/+15
| | | | | | | In the future, AttributeWithIndex won't be used anymore. Besides, it exposes the internals of the AttributeSet to outside users, which isn't goodness. llvm-svn: 173601
* Remove the last of uses that use the Attribute object as a collection of ↵Bill Wendling2013-01-231-10/+19
| | | | | | | | | attributes. Collections of attributes are handled via the AttributeSet class now. This finally frees us up to make significant changes to how attributes are structured. llvm-svn: 173228
* Have AttributeSet::getRetAttributes() return an AttributeSet instead of ↵Bill Wendling2013-01-211-2/+4
| | | | | | | | | Attribute. This further restricts the use of the Attribute class to the Attribute family of classes. llvm-svn: 173098
* Make AttributeSet::getFnAttributes() return an AttributeSet instead of an ↵Bill Wendling2013-01-211-2/+4
| | | | | | | | | Attribute. This is more code to isolate the use of the Attribute class to that of just holding one attribute instead of a collection of attributes. llvm-svn: 173094
* Use AttributeSet accessor methods instead of Attribute accessor methods.Bill Wendling2013-01-181-10/+6
| | | | | | | Further encapsulation of the Attribute object. Don't allow direct access to the Attribute object as an aggregate. llvm-svn: 172853
* Push some more methods down to hide the use of the Attribute class.Bill Wendling2013-01-181-2/+2
| | | | | | | | Because the Attribute class is going to stop representing a collection of attributes, limit the use of it as an aggregate in favor of using AttributeSet. This replaces some of the uses for querying the function attributes. llvm-svn: 172844
* Move CallGraphSCCPass.h into the Analysis tree; that's where theChandler Carruth2013-01-071-1/+1
| | | | | | implementation lives already. llvm-svn: 171746
* Move all of the header files which are involved in modelling the LLVM IRChandler Carruth2013-01-021-5/+5
| | | | | | | | | | | | | | | | | | | | | 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
* Remove Function::getParamAttributes and use the AttributeSet accessor ↵Bill Wendling2012-12-301-2/+2
| | | | | | methods instead. llvm-svn: 171255
* Rename the 'Attributes' class to 'Attribute'. It's going to represent a ↵Bill Wendling2012-12-191-7/+7
| | | | | | single attribute in the future. llvm-svn: 170502
* s/AttrListPtr/AttributeSet/g to better label what this class is going to be ↵Bill Wendling2012-12-071-9/+9
| | | | | | in the near future. llvm-svn: 169651
* Use the new script to sort the includes of every file under lib.Chandler Carruth2012-12-031-8/+8
| | | | | | | | | | | | | | | | | 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
* Make the AttrListPtr object a part of the LLVMContext.Bill Wendling2012-11-201-3/+5
| | | | | | | | | When code deletes the context, the AttributeImpls that the AttrListPtr points to are now invalid. Therefore, instead of keeping a separate managed static for the AttrListPtrs that's reference counted, move it into the LLVMContext and delete it when deleting the AttributeImpls. llvm-svn: 168354
* Add an enum for the return and function indexes into the AttrListPtr object. ↵Bill Wendling2012-10-151-4/+8
| | | | | | This gets rid of some magic numbers. llvm-svn: 165924
* Remove operator cast method in favor of querying with the correct method.Bill Wendling2012-10-141-7/+14
| | | | llvm-svn: 165899
* Create enums for the different attributes.Bill Wendling2012-10-091-1/+2
| | | | | | | We use the enums to query whether an Attributes object has that attribute. The opaque layer is responsible for knowing where that specific attribute is stored. llvm-svn: 165488
* Use method to query for attributes.Bill Wendling2012-10-041-1/+1
| | | | llvm-svn: 165207
* ArgumentPromotion: Remove ancient workaround for a bug in the C backend.Benjamin Kramer2012-09-301-19/+1
| | | | | | Fun fact: The CBE learned how to deal with this situation before it was removed. llvm-svn: 164918
* Replace some explicit compare loops with std::equal.Benjamin Kramer2012-07-191-4/+1
| | | | | | No functionality change. llvm-svn: 160501
* switch AttrListPtr::get to take an ArrayRef, simplifying a lot of clients.Chris Lattner2012-05-281-6/+3
| | | | llvm-svn: 157556
* Update inter-procedural optimizations for atomic load/store.Eli Friedman2011-08-151-2/+4
| | | | llvm-svn: 137667
OpenPOWER on IntegriCloud