aboutsummaryrefslogtreecommitdiffstats
path: root/lib/Transforms/Scalar
Commit message (Collapse)AuthorAgeFilesLines
...
| * Teach CodeGenPrepare about address spacesMatt Arsenault2013-09-061-4/+2
| | | | | | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190112 91177308-0d34-0410-b5e6-96231b3b80d8
| * Revert: r189565 - Add getUnrollingPreferences to TTIHal Finkel2013-08-291-17/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Revert unintentional commit (of an unreviewed change). Original commit message: Add getUnrollingPreferences to TTI Allow targets to customize the default behavior of the generic loop unrolling transformation. This will be used by the PowerPC backend when targeting the A2 core (which is in-order with a deep pipeline), and using more aggressive defaults is important. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189566 91177308-0d34-0410-b5e6-96231b3b80d8
| * Add getUnrollingPreferences to TTIHal Finkel2013-08-291-5/+17
| | | | | | | | | | | | | | | | | | Allow targets to customize the default behavior of the generic loop unrolling transformation. This will be used by the PowerPC backend when targeting the A2 core (which is in-order with a deep pipeline), and using more aggressive defaults is important. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189565 91177308-0d34-0410-b5e6-96231b3b80d8
| * Turn MipsOptimizeMathLibCalls into a target-independent scalar transformRichard Sandiford2013-08-233-0/+162
| | | | | | | | | | | | | | | | | | | | | | ...so that it can be used for z too. Most of the code is the same. The only real change is to use TargetTransformInfo to test when a sqrt instruction is available. The pass is opt-in because at the moment it only handles sqrt. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189097 91177308-0d34-0410-b5e6-96231b3b80d8
| * Revert r187191, which broke opt -mem2reg on the testcases included in PR16867.Nick Lewycky2013-08-132-83/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | However, opt -O2 doesn't run mem2reg directly so nobody noticed until r188146 when SROA started sending more things directly down the PromoteMemToReg path. In order to revert r187191, I also revert dependent revisions r187296, r187322 and r188146. Fixes PR16867. Does not add the testcases from that PR, but both of them should get added for both mem2reg and sroa when this revert gets unreverted. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188327 91177308-0d34-0410-b5e6-96231b3b80d8
| * Reapply r188119 now that the bug it exposed is fixed.Peter Collingbourne2013-08-121-160/+5
| | | | | | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188217 91177308-0d34-0410-b5e6-96231b3b80d8
| * Re-instate r187323 which fast-tracks promotable allocas as soon as theChandler Carruth2013-08-111-12/+81
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SROA-based analysis has enough information. This should work now that both mem2reg *and* the SSAUpdater-based AllocaPromoter have been updated to be able to promote the types of allocas that the SROA analysis detects. I've included tests for the AllocaPromoter that were only possible to write once we fast-tracked promotable allocas without rewriting them. This includes a test both for r187347 and r188145. Original commit log for r187323: """ Now that mem2reg understands how to cope with a slightly wider set of uses of an alloca, we can pre-compute promotability while analyzing an alloca for splitting in SROA. That lets us short-circuit the common case of a bunch of trivially promotable allocas. This cuts 20% to 30% off the run time of SROA for typical frontend-generated IR sequneces I'm seeing. It gets the new SROA to within 20% of ScalarRepl for such code. My current benchmark for these numbers is PR15412, but it fits the general pattern of IR emitted by Clang so it should be widely applicable. """ git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188146 91177308-0d34-0410-b5e6-96231b3b80d8
| * Finish fixing the SSAUpdater-based AllocaPromoter strategy in SROA to cope withChandler Carruth2013-08-111-2/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | the more general set of patterns that are now handled by mem2reg and that we can detect quickly while doing SROA's initial analysis. Notably, this allows it to promote through no-op bitcast and GEP sequences. A core part of the SSAUpdater approach is the ability to test whether a particular instruction is part of the set being promoted. Testing this becomes significantly more complex in the world where the operand to every load and store isn't the alloca itself. I ended up using the approach of walking up the def-chain until we find the alloca. I benchmarked this against keeping a set of pointer operands and keeping a set of the loads and stores we care about, and this one seemed faster although the difference was very small. No test case yet because currently the rewriting always "fixes" the inputs to not require this. The next patch which re-enables early promotion of easy cases in SROA will include a test case that specifically exercises this aspect of the alloca promoter. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188145 91177308-0d34-0410-b5e6-96231b3b80d8
| * Reformat some bits of AllocaPromoter and simplify the name and type ofChandler Carruth2013-08-111-21/+20
| | | | | | | | | | | | | | | | | | our visiting datastructures in the AllocaPromoter/SSAUpdater path of SROA. Also shift the order if clears around to be more consistent. No functionality changed here, this is just a cleanup. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188144 91177308-0d34-0410-b5e6-96231b3b80d8
| * Revert r188119 "Kill some duplicated code for removing unreachable BBs."Arnold Schwaighofer2013-08-101-5/+160
| | | | | | | | | | | | | | | | | | | | | | | | | | | | It is breaking builbots with libgmalloc enabled on Mac OS X. $ cd llvm ; mkdir release ; cd release $ ../configure --enable-optimized —prefix=$PWD/install $ make $ make check $ Release+Asserts/bin/llvm-lit -v --param use_gmalloc=1 --param \ gmalloc_path=/usr/lib/libgmalloc.dylib \ ../test/Instrumentation/DataFlowSanitizer/args-unreachable-bb.ll git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188142 91177308-0d34-0410-b5e6-96231b3b80d8
| * Kill some duplicated code for removing unreachable BBs.Peter Collingbourne2013-08-091-160/+5
| | | | | | | | | | | | | | | | | | | | | | This moves removeUnreachableBlocksFromFn from SimplifyCFGPass.cpp to Utils/Local.cpp and uses it to replace the implementation of llvm::removeUnreachableBlocks, which appears to do a strict subset of what removeUnreachableBlocksFromFn does. Differential Revision: http://llvm-reviews.chandlerc.com/D1334 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188119 91177308-0d34-0410-b5e6-96231b3b80d8
* | Update LLVM for merge to r187913.Stephen Hines2013-08-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add HAVE_FUTIMENS to */include/llvm/Config/config.h Update version number to 3.3 (even though this is tracking 3.4) Removed lib/Archive Added lib/Option Android.mk changes: - PathV2.cpp - SimplifyLibCalls.cpp - BlackList.cpp - VecUtils.cpp + MD5.cpp + CFG.cpp + SpecialCaseList.cpp + MachOUniversal.cpp + StructurizeCFG.cpp Change-Id: I8ee072cd0d4210a6a5492c0e6663f8464ff21386
* | Merge commit '10251753b6897adcd22cc981c0cc42f348c109de' into merge-20130807Stephen Hines2013-08-0722-2034/+2621
|\ \ | |/ | | | | | | | | | | | | Conflicts: lib/Archive/ArchiveReader.cpp lib/Support/Unix/PathV2.inc Change-Id: I29d8c1e321a4a380b6013f00bac6a8e4b593cc4e
| * JumpThreading: Turn a select instruction into branching if it allows to ↵Benjamin Kramer2013-08-071-0/+83
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | thread one half of the select. This is a common pattern coming out of simplifycfg generating gross code. a: ; preds = %entry %sel = select i1 %cmp1, double %add, double 0.000000e+00 br label %b b: %cond5 = phi double [ %sel, %a ], [ %sub, %entry ] %cmp6 = fcmp oeq double %cond5, 0.000000e+00 br i1 %cmp6, label %if.then, label %if.end becomes a: br i1 %cmp1, label %b, label %if.then b: %cond5 = phi double [ %sub, %entry ], [ %add, %a ] %cmp6 = fcmp oeq double %cond5, 0.000000e+00 br i1 %cmp6, label %if.then, label %if.end Skipping block b completely if possible. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187880 91177308-0d34-0410-b5e6-96231b3b80d8
| * Adjust file to the coding standard.Jakub Staszak2013-08-061-53/+49
| | | | | | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187808 91177308-0d34-0410-b5e6-96231b3b80d8
| * Factor FlattenCFG out from SimplifyCFGTom Stellard2013-08-064-53/+94
| | | | | | | | | | | | Patch by: Mei Ye git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187764 91177308-0d34-0410-b5e6-96231b3b80d8
| * Teach the AllocaPromoter which is wrapped around the SSAUpdaterChandler Carruth2013-07-291-15/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | infrastructure to do promotion without a domtree the same smarts about looking through GEPs, bitcasts, etc., that I just taught mem2reg about. This way, if SROA chooses to promote an alloca which still has some noisy instructions this code can cope with them. I've not used as principled of an approach here for two reasons: 1) This code doesn't really need it as we were already set up to zip through the instructions used by the alloca. 2) I view the code here as more of a hack, and hopefully a temporary one. The SSAUpdater path in SROA is a real sore point for me. It doesn't make a lot of architectural sense for many reasons: - We're likely to end up needing the domtree anyways in a subsequent pass, so why not compute it earlier and use it. - In the future we'll likely end up needing the domtree for parts of the inliner itself. - If we need to we could teach the inliner to preserve the domtree. Part of the re-work of the pass manager will allow this to be very powerful even in large SCCs with many functions. - Ultimately, computing a domtree has gotten significantly faster since the original SSAUpdater-using code went into ScalarRepl. We no longer use domfrontiers, and much of domtree is lazily done based on queries rather than eagerly. - At this point keeping the SSAUpdater-based promotion saves a total of 0.7% on a build of the 'opt' tool for me. That's not a lot of performance given the complexity! So I'm leaving this a bit ugly in the hope that eventually we just remove all of this nonsense. I can't even readily test this because this code isn't reachable except through SROA. When I re-instate the patch that fast-tracks allocas already suitable for promotion, I'll add a testcase there that failed before this change. Before that, SROA will fix any test case I give it. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187347 91177308-0d34-0410-b5e6-96231b3b80d8
| * Temporarily revert r187323 until I update SSAUpdater to match mem2reg.Chandler Carruth2013-07-281-81/+12
| | | | | | | | | | | | I forgot that we had two totally independent things here. :: sigh :: git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187327 91177308-0d34-0410-b5e6-96231b3b80d8
| * Now that mem2reg understands how to cope with a slightly wider set ofChandler Carruth2013-07-281-12/+81
| | | | | | | | | | | | | | | | | | | | | | | | uses of an alloca, we can pre-compute promotability while analyzing an alloca for splitting in SROA. That lets us short-circuit the common case of a bunch of trivially promotable allocas. This cuts 20% to 30% off the run time of SROA for typical frontend-generated IR sequneces I'm seeing. It gets the new SROA to within 20% of ScalarRepl for such code. My current benchmark for these numbers is PR15412, but it fits the general pattern of IR emitted by Clang so it should be widely applicable. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187323 91177308-0d34-0410-b5e6-96231b3b80d8
| * Thread DataLayout through the callers and into mem2reg. This will beChandler Carruth2013-07-282-2/+2
| | | | | | | | | | | | | | useful in a subsequent patch, but causes an unfortunate amount of noise, so I pulled it out into a separate patch. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187322 91177308-0d34-0410-b5e6-96231b3b80d8
| * Don't use all the #ifdefs to hide the stats counters and instead rely onChandler Carruth2013-07-271-18/+0
| | | | | | | | | | | | | | | | | | their being optimized out in debug mode. Realistically, this just isn't going to be the slow part anyways. This also fixes unused variable warnings that are breaking LLD build bots. =/ I didn't see these at first, and kept losing track of the fact that they were broken. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187297 91177308-0d34-0410-b5e6-96231b3b80d8
| * Reimplement isPotentiallyReachable to make nocapture deduction much stronger.Nick Lewycky2013-07-272-2/+2
| | | | | | | | | | | | | | | | | | | | | | Adds unit tests for it too. Split BasicBlockUtils into an analysis-half and a transforms-half, and put the analysis bits into a new Analysis/CFG.{h,cpp}. Promote isPotentiallyReachable into llvm::isPotentiallyReachable and move it into Analysis/CFG. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187283 91177308-0d34-0410-b5e6-96231b3b80d8
| * SimplifyCFG: Use parallel-and and parallel-or mode to consolidate branch ↵Tom Stellard2013-07-272-23/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | conditions Merge consecutive if-regions if they contain identical statements. Both transformations reduce number of branches. The transformation is guarded by a target-hook, and is currently enabled only for +R600, but the correctness has been tested on X86 target using a variety of CPU benchmarks. Patch by: Mei Ye git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187278 91177308-0d34-0410-b5e6-96231b3b80d8
| * TRE: Move class into anonymous namespace.Benjamin Kramer2013-07-241-4/+6
| | | | | | | | | | | | While there shrink a dangerously large SmallPtrSet. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187050 91177308-0d34-0410-b5e6-96231b3b80d8
| * Fix a problem I introduced in r187029 where we would over-eagerlyChandler Carruth2013-07-241-3/+9
| | | | | | | | | | | | | | | | schedule an alloca for another iteration in SROA. This only showed up with a mixture of promotable and unpromotable selects and phis. Added a test case for this. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187031 91177308-0d34-0410-b5e6-96231b3b80d8
| * Fix PR16687 where we were incorrectly promoting an alloca that hadChandler Carruth2013-07-241-12/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | pending speculation for a phi node. The problem here is that we were using growth of the specluation set as an indicator of whether speculation would occur, and if the phi node is already in the set we don't see it grow. This is a symptom of the fact that this signal is a total hack. Unfortunately, I couldn't really come up with a non-hacky way of signaling that promotion remains valid *after* speculation occurs, such that we only speculate when all else looks good for promotion. In the end, I went with at least a much more explicit approach of doing the work of queuing inside the phi and select processing and setting a preposterously named flag to convey that we're in the special state of requiring speculating before promotion. Thanks to Richard Trieu and Nick Lewycky for the excellent work reducing a testcase for this from a pretty giant, nasty assert in a big application. =] The testcase was excellent. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187029 91177308-0d34-0410-b5e6-96231b3b80d8
| * Remove extraneous null statement. No functionality change!Nick Lewycky2013-07-221-1/+1
| | | | | | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186893 91177308-0d34-0410-b5e6-96231b3b80d8
| * Use switch instead of if. No functionality change.Jakub Staszak2013-07-221-14/+17
| | | | | | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186892 91177308-0d34-0410-b5e6-96231b3b80d8
| * OldPtr is llvm::Instruction. Remove unneeded cast<>.Jakub Staszak2013-07-221-1/+1
| | | | | | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186880 91177308-0d34-0410-b5e6-96231b3b80d8
| * Change tabs to spaces.Jakub Staszak2013-07-221-2/+2
| | | | | | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186877 91177308-0d34-0410-b5e6-96231b3b80d8
| * Fix spelling and grammarMatt Arsenault2013-07-221-12/+12
| | | | | | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186858 91177308-0d34-0410-b5e6-96231b3b80d8
| * SROA: Microoptimization: Remove dead entries first, then sort.Benjamin Kramer2013-07-201-9/+4
| | | | | | | | | | | | While there replace an explicit struct with std::mem_fun. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186761 91177308-0d34-0410-b5e6-96231b3b80d8
| * Cleanup the stats counters for the new implementation. These actuallyChandler Carruth2013-07-191-12/+36
| | | | | | | | | | | | count the right things and have the right names. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186667 91177308-0d34-0410-b5e6-96231b3b80d8
| * Fix another assert failure very similar to PR16651's test case. ThisChandler Carruth2013-07-191-0/+2
| | | | | | | | | | | | | | test case came from Benjamin and found the parallel bug in the vector promotion code. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186666 91177308-0d34-0410-b5e6-96231b3b80d8
| * Try to move to a more reasonable set of naming conventions given the newChandler Carruth2013-07-191-322/+305
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | implementation of the SROA algorithm. We were using the term 'partition' in many places that no longer ever represented an actual partition, but rather just an arbitrary slice of an alloca. No functionality change intended here. Mostly just renaming of types, functions, variables, and rewording of comments. Several comments were rewritten to make a lot more sense in the new structure of things. The stats are still weird and not reflective of how this really works. I'll fix those up in a separate patch as it is a touch more semantic of a change... git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186659 91177308-0d34-0410-b5e6-96231b3b80d8
| * A long overdue cleanup in SROA to use 'DL' instead of 'TD' for theChandler Carruth2013-07-191-123/+123
| | | | | | | | | | | | DataLayout variables. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186656 91177308-0d34-0410-b5e6-96231b3b80d8
| * Fix PR16651, an assert introduced in my recent re-work of the innards ofChandler Carruth2013-07-191-9/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | SROA. The crux of the issue is that now we track uses of a partition of the alloca in two places: the iterators over the partitioning uses and the previously collected split uses vector. We weren't accounting for the fact that the split uses might invalidate integer widening in ways other than due to their width (in this case due to being volatile). Further reduced testcase added to the tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186655 91177308-0d34-0410-b5e6-96231b3b80d8
| * Reapply r186316 with a fix for one bug where the code could walk off theChandler Carruth2013-07-181-1255/+976
| | | | | | | | | | | | | | | | | | | | | | | | end of a vector. This was found with ASan. I've had one other report of a crasher, but thus far been unable to reproduce the crash. It may well be fixed with this version, and if not I'd like to get more information from the build bots about what is happening. See r186316 for the full commit log for the new implementation of the SROA algorithm. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186565 91177308-0d34-0410-b5e6-96231b3b80d8
| * Add 'const' qualifiers to static const char* variables.Craig Topper2013-07-161-1/+1
| | | | | | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186371 91177308-0d34-0410-b5e6-96231b3b80d8
| * Remove trailing whitespaceStephen Lin2013-07-151-36/+36
| | | | | | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186333 91177308-0d34-0410-b5e6-96231b3b80d8
| * Revert r186316 while I track down an ASan failure and an assert fromChandler Carruth2013-07-151-972/+1255
| | | | | | | | | | | | | | | | | | | | | | a bot. This reverts the commit which introduced a new implementation of the fancy SROA pass designed to reduce its overhead. I'll skip the huge commit log here, refer to r186316 if you're looking for how this all works and why it works that way. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186332 91177308-0d34-0410-b5e6-96231b3b80d8
| * Reimplement SROA yet again. Same fundamental principle, but a totallyChandler Carruth2013-07-151-1255/+972
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | different core implementation strategy. Previously, SROA would build a relatively elaborate partitioning of an alloca, associate uses with each partition, and then rewrite the uses of each partition in an attempt to break apart the alloca into chunks that could be promoted. This was very wasteful in terms of memory and compile time because regardless of how complex the alloca or how much we're able to do in breaking it up, all of the datastructure work to analyze the partitioning was done up front. The new implementation attempts to form partitions of the alloca lazily and on the fly, rewriting the uses that make up that partition as it goes. This has a few significant effects: 1) Much simpler data structures are used throughout. 2) No more double walk of the recursive use graph of the alloca, only walk it once. 3) No more complex algorithms for associating a particular use with a particular partition. 4) PHI and Select speculation is simplified and happens lazily. 5) More precise information is available about a specific use of the alloca, removing the need for some side datastructures. Ultimately, I think this is a much better implementation. It removes about 300 lines of code, but arguably removes more like 500 considering that some code grew in the process of being factored apart and cleaned up for this all to work. I've re-used as much of the old implementation as possible, which includes the lion's share of code in the form of the rewriting logic. The interesting new logic centers around how the uses of a partition are sorted, and split into actual partitions. Each instruction using a pointer derived from the alloca gets a 'Partition' entry. This name is totally wrong, but I'll do a rename in a follow-up commit as there is already enough churn here. The entry describes the offset range accessed and the nature of the access. Once we have all of these entries we sort them in a very specific way: increasing order of begin offset, followed by whether they are splittable uses (memcpy, etc), followed by the end offset or whatever. Sorting by splittability is important as it simplifies the collection of uses into a partition. Once we have these uses sorted, we walk from the beginning to the end building up a range of uses that form a partition of the alloca. Overlapping unsplittable uses are merged into a single partition while splittable uses are broken apart and carried from one partition to the next. A partition is also introduced to bridge splittable uses between the unsplittable regions when necessary. I've looked at the performance PRs fairly closely. PR15471 no longer will even load (the module is invalid). Not sure what is up there. PR15412 improves by between 5% and 10%, however it is nearly impossible to know what is holding it up as SROA (the entire pass) takes less time than reading the IR for that test case. The analysis takes the same time as running mem2reg on the final allocas. I suspect (without much evidence) that the new implementation will scale much better however, and it is just the small nature of the test cases that makes the changes small and noisy. Either way, it is still simpler and cleaner I think. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186316 91177308-0d34-0410-b5e6-96231b3b80d8
| * Use SmallVectorImpl& instead of SmallVector to avoid repeating small vector ↵Craig Topper2013-07-145-35/+39
| | | | | | | | | | | | size. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186274 91177308-0d34-0410-b5e6-96231b3b80d8
| * LFTR improvement to avoid truncation.Andrew Trick2013-07-121-6/+32
| | | | | | | | | | | | This is a reimplemntation of the patch originally in r186107. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186215 91177308-0d34-0410-b5e6-96231b3b80d8
| * Cleanup LFTR logic.Andrew Trick2013-07-121-28/+9
| | | | | | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186214 91177308-0d34-0410-b5e6-96231b3b80d8
| * Cleanup: rename a variable to make the logic easier to follow.Andrew Trick2013-07-121-7/+7
| | | | | | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186213 91177308-0d34-0410-b5e6-96231b3b80d8
| * Revert "indvars: Improve LFTR by eliminating truncation when comparingChandler Carruth2013-07-121-23/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | against a constant." This reverts commit r186107. It didn't handle wrapping arithmetic in the loop correctly and thus caused the following C program to count from 0 to UINT64_MAX instead of from 0 to 255 as intended: #include <stdio.h> int main() { unsigned char first = 0, last = 255; do { printf("%d\n", first); } while (first++ != last); } Full test case and instructions to reproduce with just the -indvars pass sent to the original review thread rather than to r186107's commit. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186152 91177308-0d34-0410-b5e6-96231b3b80d8
| * indvars: Improve LFTR by eliminating truncation when comparing against a ↵Andrew Trick2013-07-111-4/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | constant. Patch by Michele Scandale! Adds a special handling of the case where, during the loop exit condition rewriting, the exit value is a constant of bitwidth lower than the type of the induction variable: instead of introducing a trunc operation in order to match correctly the operand types, it allows to convert the constant value to an equivalent constant, depending on the initial value of the induction variable and the trip count, in order have an equivalent comparison between the induction variable and the new constant. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186107 91177308-0d34-0410-b5e6-96231b3b80d8
| * Teach TailRecursionElimination to handle certain cases of nocapture escaping ↵Michael Gottesman2013-07-111-64/+85
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | allocas. Without the changes introduced into this patch, if TRE saw any allocas at all, TRE would not perform TRE *or* mark callsites with the tail marker. Because TRE runs after mem2reg, this inadequacy is not a death sentence. But given a callsite A without escaping alloca argument, A may not be able to have the tail marker placed on it due to a separate callsite B having a write-back parameter passed in via an argument with the nocapture attribute. Assume that B is the only other callsite besides A and B only has nocapture escaping alloca arguments (*NOTE* B may have other arguments that are not passed allocas). In this case not marking A with the tail marker is unnecessarily conservative since: 1. By assumption A has no escaping alloca arguments itself so it can not access the caller's stack via its arguments. 2. Since all of B's escaping alloca arguments are passed as parameters with the nocapture attribute, we know that B does not stash said escaping allocas in a manner that outlives B itself and thus could be accessed indirectly by A. With the changes introduced by this patch: 1. If we see any escaping allocas passed as a capturing argument, we do nothing and bail early. 2. If we do not see any escaping allocas passed as captured arguments but we do see escaping allocas passed as nocapture arguments: i. We do not perform TRE to avoid PR962 since the code generator produces significantly worse code for the dynamic allocas that would be created by the TRE algorithm. ii. If we do not return twice, mark call sites without escaping allocas with the tail marker. *NOTE* This excludes functions with escaping nocapture allocas. 3. If we do not see any escaping allocas at all (whether captured or not): i. If we do not have usage of setjmp, mark all callsites with the tail marker. ii. If there are no dynamic/variable sized allocas in the function, attempt to perform TRE on all callsites in the function. Based off of a patch by Nick Lewycky. rdar://14324281. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186057 91177308-0d34-0410-b5e6-96231b3b80d8
| * Reassociate: Remove unnecessary default operator=.Benjamin Kramer2013-07-061-10/+0
| | | | | | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185757 91177308-0d34-0410-b5e6-96231b3b80d8
generated by cgit v1.1 at 2025-09-13 06:48:31 +0000