summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Utils
Commit message (Collapse)AuthorAgeFilesLines
* Re-commit r208025, reverted in r208030, with a fix for a conformance issueRichard Smith2014-05-061-3/+3
| | | | | | which GCC detects and Clang does not! llvm-svn: 208033
* Revert r208025, which made buildbots unhappy for unknown reasons.Richard Smith2014-05-061-3/+3
| | | | llvm-svn: 208030
* Add llvm::function_ref (and a couple of uses of it), representing a ↵Richard Smith2014-05-061-3/+3
| | | | | | type-erased reference to a callable object. llvm-svn: 208025
* Teach GlobalDCE how to remove empty global_ctor entries.Nico Weber2014-05-022-0/+182
| | | | | | | | | | | | | | | | | This moves most of GlobalOpt's constructor optimization code out of GlobalOpt into Transforms/Utils/CDtorUtils.{h,cpp}. The public interface is a single function OptimizeGlobalCtorsList() that takes a predicate returning which constructors to remove. GlobalOpt calls this with a function that statically evaluates all constructors, just like it did before. This part of the change is behavior-preserving. Also add a call to this from GlobalDCE with a filter that removes global constructors that contain a "ret" instruction and nothing else – this fixes PR19590. llvm-svn: 207856
* Fold strlen(expr ? "str1" : "str2") to x ? len1 : len2. This fires about 330 ↵Nick Lewycky2014-05-021-0/+15
| | | | | | times in a bootstrap of clang. llvm-svn: 207828
* Patch for function cloning to inline all blocks whose address is takenGerolf Hoflehner2014-04-301-34/+106
| | | | | | | | | | | | | Not all address taken blocks get inlined. The reason is that a blocks new address is known only when it is cloned. But e.g. a branch instruction in a different block could need that address earlier while it gets cloned. The solution is to collect the set of all blocks that can potentially get inlined and compute a new block address up front. Then clone and cleanup. rdar://16427209 llvm-svn: 207713
* Add optimization remarks to the loop unroller and vectorizer.Diego Novillo2014-04-291-0/+14
| | | | | | | | | | | | | | | Summary: This calls emitOptimizationRemark from the loop unroller and vectorizer at the point where they make a positive transformation. For the vectorizer, it reports vectorization and interleave factors. For the loop unroller, it reports all the different supported types of unrolling. Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D3456 llvm-svn: 207528
* Fix a typo in commentMichael Zolotukhin2014-04-291-1/+1
| | | | llvm-svn: 207499
* Fix rampant quadratic behavior in UpdatePHINodes. The operation ofChandler Carruth2014-04-281-23/+40
| | | | | | | | | | | | | | | | | | | | | | | mapping from a basic block to an incoming value, either for removal or just lookup, is linear in the number of predecessors, and we were doing this for every entry in the 'Preds' list which is in many cases almost all of them! Unfortunately, the fixes are quite ugly. PHI nodes just don't make this operation easy. The efficient way to fix this is to have a clever 'remove_if' operation on PHI nodes that lets us do a single pass over all the incoming values of the original PHI node, extracting the ones we care about. Then we could quickly construct the new phi node from this list. This would remove the remaining underlying quadratic movement of unrelated incoming values and the need for silly backwards looping to "minimize" how often we hit the quadratic case. This is the last obvious fix for PR19499. It shaves another 20% off the compile time for me, and while UpdatePHINodes remains in the profile, most of the time is now stemming from the well known inefficiencies of LVI and jump threading. llvm-svn: 207409
* [C++] Use 'nullptr'.Craig Topper2014-04-283-4/+4
| | | | llvm-svn: 207394
* RecursivelyDeleteTriviallyDeadInstructions() could removeGerolf Hoflehner2014-04-261-1/+9
| | | | | | | | | | | more than 1 instruction. The caller need to be aware of this and adjust instruction iterators accordingly. rdar://16679376 Repaired r207302. llvm-svn: 207309
* Restore CloneFunction.cpp which got accidentlyGerolf Hoflehner2014-04-261-92/+33
| | | | | | overwritten by previous backout of r207303 llvm-svn: 207308
* Revert commit r207302 since build failuresGerolf Hoflehner2014-04-262-42/+93
| | | | | | have been reported. llvm-svn: 207303
* RecursivelyDeleteTriviallyDeadInstructions() could removeGerolf Hoflehner2014-04-261-1/+9
| | | | | | | | | more than 1 instruction. The caller need to be aware of this and adjust instruction iterators accordingly. rdar://16679376 llvm-svn: 207302
* Unbreak the gdb buildbot by not lowering dbg.declare intrinsics for arrays.Adrian Prantl2014-04-251-1/+7
| | | | llvm-svn: 207284
* This reapplies r207235 with an additional bugfixes caught by the msanAdrian Prantl2014-04-251-8/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | buildbot - do not insert debug intrinsics before phi nodes. Debug info for optimized code: Support variables that are on the stack and described by DBG_VALUEs during their lifetime. Previously, when a variable was at a FrameIndex for any part of its lifetime, this would shadow all other DBG_VALUEs and only a single fbreg location would be emitted, which in fact is only valid for a small range and not the entire lexical scope of the variable. The included dbg-value-const-byref testcase demonstrates this. This patch fixes this by Local - emitting dbg.value intrinsics for allocas that are passed by reference - dropping all dbg.declares (they are now fully lowered to dbg.values) SelectionDAG - renamed constructors for SDDbgValue for better readability. - fix UserValue::match() to handle indirect values correctly - not inserting an MMI table entries for dbg.values that describe allocas. - lowering dbg.values that describe allocas into *indirect* DBG_VALUEs. CodeGenPrepare - leaving dbg.values for an alloca were they are (see comment) Other - regenerated/updated instcombine.ll testcase and included source rdar://problem/16679879 http://reviews.llvm.org/D3374 llvm-svn: 207269
* Revert "This reapplies r207130 with an additional testcase+and a missing ↵Adrian Prantl2014-04-251-14/+8
| | | | | | | | check for" This reverts commit 207235 to investigate msan buildbot breakage. llvm-svn: 207250
* Reapply r207135 without modifications.Adrian Prantl2014-04-251-17/+3
| | | | | | | | | | Debug info: Let dbg.values inserted by LowerDbgDeclare inherit the location of the dbg.value. This gets rid of tons of redundant variable DIEs in subscopes. rdar://problem/14874886, rdar://problem/16679936 llvm-svn: 207236
* This reapplies r207130 with an additional testcase+and a missing check forAdrian Prantl2014-04-251-8/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | AllocaInst that was missing in one location. Debug info for optimized code: Support variables that are on the stack and described by DBG_VALUEs during their lifetime. Previously, when a variable was at a FrameIndex for any part of its lifetime, this would shadow all other DBG_VALUEs and only a single fbreg location would be emitted, which in fact is only valid for a small range and not the entire lexical scope of the variable. The included dbg-value-const-byref testcase demonstrates this. This patch fixes this by Local - emitting dbg.value intrinsics for allocas that are passed by reference - dropping all dbg.declares (they are now fully lowered to dbg.values) SelectionDAG - renamed constructors for SDDbgValue for better readability. - fix UserValue::match() to handle indirect values correctly - not inserting an MMI table entries for dbg.values that describe allocas. - lowering dbg.values that describe allocas into *indirect* DBG_VALUEs. CodeGenPrepare - leaving dbg.values for an alloca were they are (see comment) Other - regenerated/updated instcombine.ll testcase and included source rdar://problem/16679879 http://reviews.llvm.org/D3374 llvm-svn: 207235
* [C++] Use 'nullptr'. Transforms edition.Craig Topper2014-04-2527-398/+403
| | | | llvm-svn: 207196
* Revert "This reapplies r207130 with an additional testcase+and a missing ↵Adrian Prantl2014-04-251-14/+8
| | | | | | | | check for" Typo in testcase. llvm-svn: 207166
* This reapplies r207130 with an additional testcase+and a missing check forAdrian Prantl2014-04-251-8/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | AllocaInst that was missing in one location. Debug info for optimized code: Support variables that are on the stack and described by DBG_VALUEs during their lifetime. Previously, when a variable was at a FrameIndex for any part of its lifetime, this would shadow all other DBG_VALUEs and only a single fbreg location would be emitted, which in fact is only valid for a small range and not the entire lexical scope of the variable. The included dbg-value-const-byref testcase demonstrates this. This patch fixes this by Local - emitting dbg.value intrinsics for allocas that are passed by reference - dropping all dbg.declares (they are now fully lowered to dbg.values) SelectionDAG - renamed constructors for SDDbgValue for better readability. - fix UserValue::match() to handle indirect values correctly - not inserting an MMI table entries for dbg.values that describe allocas. - lowering dbg.values that describe allocas into *indirect* DBG_VALUEs. CodeGenPrepare - leaving dbg.values for an alloca were they are (see comment) Other - regenerated/updated instcombine.ll testcase and included source rdar://problem/16679879 http://reviews.llvm.org/D3374 llvm-svn: 207165
* Revert "Debug info for optimized code: Support variables that are on the ↵Adrian Prantl2014-04-251-14/+8
| | | | | | | | stack and" This reverts commit 207130 for buildbot breakage. llvm-svn: 207162
* Revert "Debug info: Let dbg.values inserted by LowerDbgDeclare inherit the ↵Adrian Prantl2014-04-241-3/+17
| | | | | | | | location" This reverts commit 207130 for buildbot breakage. llvm-svn: 207159
* Debug info: Let dbg.values inserted by LowerDbgDeclare inherit the locationAdrian Prantl2014-04-241-17/+3
| | | | | | | | | of the dbg.value. This gets rid of tons of redundant variable DIEs in subscopes. rdar://problem/14874886, rdar://problem/16679936 llvm-svn: 207135
* Debug info for optimized code: Support variables that are on the stack andAdrian Prantl2014-04-241-8/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | described by DBG_VALUEs during their lifetime. Previously, when a variable was at a FrameIndex for any part of its lifetime, this would shadow all other DBG_VALUEs and only a single fbreg location would be emitted, which in fact is only valid for a small range and not the entire lexical scope of the variable. The included dbg-value-const-byref testcase demonstrates this. This patch fixes this by Local - emitting dbg.value intrinsics for allocas that are passed by reference - dropping all dbg.declares (they are now fully lowered to dbg.values) SelectionDAG - renamed constructors for SDDbgValue for better readability. - fix UserValue::match() to handle indirect values correctly - not inserting an MMI table entries for dbg.values that describe allocas. - lowering dbg.values that describe allocas into *indirect* DBG_VALUEs. CodeGenPrepare - leaving dbg.values for an alloca were they are (see comment) Other - regenerated/updated instcombine-intrinsics testcase and included source rdar://problem/16679879 http://reviews.llvm.org/D3374 llvm-svn: 207130
* Remove more default address space argument usage.Matt Arsenault2014-04-233-6/+11
| | | | | | These places are inconsequential in practice. llvm-svn: 207021
* [Modules] Fix potential ODR violations by sinking the DEBUG_TYPEChandler Carruth2014-04-2216-18/+32
| | | | | | | | | | | | | | | | | 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
* [Modules] Make Support/Debug.h modular. This requires it to not changeChandler Carruth2014-04-214-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | behavior based on other files defining DEBUG_TYPE, which means it cannot define DEBUG_TYPE at all. This is actually better IMO as it forces folks to define relevant DEBUG_TYPEs for their files. However, it requires all files that currently use DEBUG(...) to define a DEBUG_TYPE if they don't already. I've updated all such files in LLVM and will do the same for other upstream projects. This still leaves one important change in how LLVM uses the DEBUG_TYPE macro going forward: we need to only define the macro *after* header files have been #include-ed. Previously, this wasn't possible because Debug.h required the macro to be pre-defined. This commit removes that. By defining DEBUG_TYPE after the includes two things are fixed: - Header files that need to provide a DEBUG_TYPE for some inline code can do so by defining the macro before their inline code and undef-ing it afterward so the macro does not escape. - We no longer have rampant ODR violations due to including headers with different DEBUG_TYPE definitions. This may be mostly an academic violation today, but with modules these types of violations are easy to check for and potentially very relevant. Where necessary to suppor headers with DEBUG_TYPE, I have moved the definitions below the includes in this commit. I plan to move the rest of the DEBUG_TYPE macros in LLVM in subsequent commits; this one is big enough. The comments in Debug.h, which were hilariously out of date already, have been updated to reflect the recommended practice going forward. llvm-svn: 206822
* Fix PR7272 in -tailcallelim instead of the inlinerReid Kleckner2014-04-211-8/+1
| | | | | | | | | | | | | | | | The -tailcallelim pass should be checking if byval or inalloca args can be captured before marking calls as tail calls. This was the real root cause of PR7272. With a better fix in place, revert the inliner change from r105255. The test case it introduced still passes and has been moved to test/Transforms/Inline/byval-tail-call.ll. Reviewers: chandlerc Differential Revision: http://reviews.llvm.org/D3403 llvm-svn: 206789
* Fix bug 19437 - Only add discriminators for DWARF 4 and above.Diego Novillo2014-04-171-2/+7
| | | | | | | | | | | | | | Summary: This prevents the discriminator generation pass from triggering if the DWARF version being used in the module is prior to 4. Reviewers: echristo, dblaikie CC: llvm-commits Differential Revision: http://reviews.llvm.org/D3413 llvm-svn: 206507
* remove some dead codeNuno Lopes2014-04-172-8/+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
* Add lifetime markers for allocas created to hold byval arguments, make themJulien Lerouge2014-04-151-0/+1
| | | | | | appear in the InlineFunctionInfo. llvm-svn: 206308
* Split byval argument initialization so the memcpy(s) are injected at theJulien Lerouge2014-04-151-29/+42
| | | | | | beginning of the first new block after inlining. llvm-svn: 206307
* Implement depth_first and inverse_depth_first range factory functions.David Blaikie2014-04-111-3/+4
| | | | | | | | | | | | | | Also updated as many loops as I could find using df_begin/idf_begin - strangely I found no uses of idf_begin. Is that just used out of tree? Also a few places couldn't use df_begin because either they used the member functions of the depth first iterators or had specific ordering constraints (I added a comment in the latter case). Based on a patch by Jim Grosbach. (Jim - you just had iterator_range<T> where you needed iterator_range<idf_iterator<T>>) llvm-svn: 206016
* C++11: convert verbose loops to range-based loops.Adrian Prantl2014-03-271-7/+6
| | | | llvm-svn: 204981
* CloneFunction: Clone all attributes, including the CCReid Kleckner2014-03-261-14/+16
| | | | | | | | | | | | | | | | Summary: Tested with a unit test because we don't appear to have any transforms that use this other than ASan, I think. Fixes PR17935. Reviewers: nicholas CC: llvm-commits Differential Revision: http://llvm-reviews.chandlerc.com/D3194 llvm-svn: 204866
* Remove LowerInvoke's obsolete "-enable-correct-eh-support" optionMark Seaborn2014-03-201-507/+8
| | | | | | | | | | | | | | | This option caused LowerInvoke to generate code using SJLJ-based exception handling, but there is no code left that interprets the jmp_buf stack that the resulting code maintained (llvm.sjljeh.jblist). This option has been obsolete for a while, and replaced by SjLjEHPrepare. This leaves the default behaviour of LowerInvoke, which is to convert invokes to calls. Differential Revision: http://llvm-reviews.chandlerc.com/D3136 llvm-svn: 204388
* Set debug info for instructions inserted in SplitBlockAndInsertIfThen.Evgeniy Stepanov2014-03-191-0/+5
| | | | llvm-svn: 204230
* [C++11] Change DebugInfoFinder to use range-based loopsAlon Mishne2014-03-181-8/+2
| | | | | | Also changes the iterators to return actual DI type over MDNode. llvm-svn: 204130
* Allow switch-to-lookup table for tables with holes by adding bitmask checkHans Wennborg2014-03-121-5/+61
| | | | | | | | | | | | | | | | | | | | | | | | This allows us to generate table lookups for code such as: unsigned test(unsigned x) { switch (x) { case 100: return 0; case 101: return 1; case 103: return 2; case 105: return 3; case 107: return 4; case 109: return 5; case 110: return 6; default: return f(x); } } Since cases 102, 104, etc. are not constants, the lookup table has holes in those positions. We therefore guard the table lookup with a bitmask check. Patch by Jasper Neumann! llvm-svn: 203694
* Revert r203488 and r203520.Evan Cheng2014-03-121-67/+62
| | | | llvm-svn: 203687
* Cloning a function now also clones its debug metadata if ↵Alon Mishne2014-03-121-0/+58
| | | | | | 'ModuleLevelChanges' is true. llvm-svn: 203662
* Follow up to r203488. Code clean up to eliminate a lot of copy+paste.Evan Cheng2014-03-111-215/+35
| | | | llvm-svn: 203520
* For functions with ARM target specific calling convention, when simplify-libcallEvan Cheng2014-03-101-48/+233
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | optimize a call to a llvm intrinsic to something that invovles a call to a C library call, make sure it sets the right calling convention on the call. e.g. extern double pow(double, double); double t(double x) { return pow(10, x); } Compiles to something like this for AAPCS-VFP: define arm_aapcs_vfpcc double @t(double %x) #0 { entry: %0 = call double @llvm.pow.f64(double 1.000000e+01, double %x) ret double %0 } declare double @llvm.pow.f64(double, double) #1 Simplify libcall (part of instcombine) will turn the above into: define arm_aapcs_vfpcc double @t(double %x) #0 { entry: %__exp10 = call double @__exp10(double %x) #1 ret double %__exp10 } declare double @__exp10(double) The pre-instcombine code works because calls to LLVM builtins are special. Instruction selection will chose the right calling convention for the call. However, the code after instcombine is wrong. The call to __exp10 will use the C calling convention. I can think of 3 options to fix this. 1. Make "C" calling convention just work since the target should know what CC is being used. This doesn't work because each function can use different CC with the "pcs" attribute. 2. Have Clang add the right CC keyword on the calls to LLVM builtin. This will work but it doesn't match the LLVM IR specification which states these are "Standard C Library Intrinsics". 3. Fix simplify libcall so the resulting calls to the C routines will have the proper CC keyword. e.g. %__exp10 = call arm_aapcs_vfpcc double @__exp10(double %x) #1 This works and is the solution I implemented here. Both solutions #2 and #3 would work. After carefully considering the pros and cons, I decided to implement #3 for the following reasons. 1. It doesn't change the "spec" of the intrinsics. 2. It's a self-contained fix. There are a couple of potential downsides. 1. There could be other places in the optimizer that is broken in the same way that's not addressed by this. 2. There could be other calling conventions that need to be propagated by simplify-libcall that's not handled. But for now, this is the fix that I'm most comfortable with. llvm-svn: 203488
* SimplifyCFG: Simplify the weight scaling algorithm.Benjamin Kramer2014-03-091-15/+6
| | | | | | No change in functionality. llvm-svn: 203413
* [C++11] Add range based accessors for the Use-Def chain of a Value.Chandler Carruth2014-03-0912-120/+92
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Replace OwningPtr<T> with std::unique_ptr<T>.Ahmed Charles2014-03-061-3/+2
| | | | | | | | | | 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
* [Layering] Move DebugInfo.h into the IR library where its implementationChandler Carruth2014-03-065-5/+5
| | | | | | already lives. llvm-svn: 203046
* [Layering] Move DIBuilder.h into the IR library where its implementationChandler Carruth2014-03-063-3/+3
| | | | | | already lives. llvm-svn: 203038
OpenPOWER on IntegriCloud