summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms
Commit message (Collapse)AuthorAgeFilesLines
* GlobalDCE: Deduplicate code. NFCI.Peter Collingbourne2016-10-251-35/+18
| | | | llvm-svn: 285048
* Merge two if conditions into one. NFCI.Davide Italiano2016-10-241-3/+2
| | | | llvm-svn: 285008
* add-discriminators: Fix handling of lexical scopes.Adrian Prantl2016-10-241-9/+13
| | | | | | | | | | | | | | | This fixes a bug in the handling of lexical scopes, when more than one scope is defined on the same line or functions are inlined into call sites that are on the same line as the function definition. This situation can easily happen in macro expansions. The problem is solved by introducing a SmallDenseMap<DIScope *, DILexicalBlockFile *, 1> that keeps track of all the different lexical scopes that share a line/file location. Fixes PR30681. llvm-svn: 284998
* Check the number of Args in LibCallsShrinkWrap.Rong Xu2016-10-241-0/+2
| | | | | | Some library fucntions can have no argument. llvm-svn: 284989
* [EarlyCSE] Optimize MemoryPhis and reduce memory clobber queries w/ MemorySSAGeoff Berry2016-10-241-10/+44
| | | | | | | | | | | | | | | | | | | | | Summary: When using MemorySSA, re-optimize MemoryPhis when removing a store since this may create MemoryPhis with all identical arguments. Also, when using MemorySSA to check if two MemoryUses are reading from the same version of the heap, use the defining access instead of calling getClobberingAccess, since the latter can currently result in many more AA calls. Once the MemorySSA use optimization tracking changes are done, we can remove this limitation, which should result in more loads being CSE'd. Reviewers: dberlin Subscribers: mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D25881 llvm-svn: 284984
* Revert 284971.Nico Weber2016-10-241-73/+38
| | | | | | | | | It seems to break selfhost on some bots, see e.g. http://lab.llvm.org:8011/builders/clang-x86-windows-msvc2015/builds/21 http://lab.llvm.org:8011/builders/clang-ppc64be-linux-multistage/builds/20 http://lab.llvm.org:8011/builders/clang-ppc64be-linux-lnt/builds/22 llvm-svn: 284979
* [JumpThreading] Unfold selects that depend on the same conditionPablo Barrio2016-10-241-38/+73
| | | | | | | | | | | | | | | | | | Summary: These are good candidates for jump threading. This enables later opts (such as InstCombine) to combine instructions from the selects with instructions out of the selects. SimplifyCFG will fold the select again if unfolding wasn't worth it. Patch by James Molloy and Pablo Barrio. Reviewers: reames, bkramer, mcrosier, gberry, haicheng, jmolloy, sebpop Subscribers: jojo, rengolin, llvm-commits Differential Revision: https://reviews.llvm.org/D25477 llvm-svn: 284971
* Now that VS2013 is gone, make a memoryssa structure an anonymous union againDaniel Berlin2016-10-221-4/+4
| | | | llvm-svn: 284910
* [CtorUtils] Modernize. No functional changes intended.Davide Italiano2016-10-221-5/+5
| | | | llvm-svn: 284904
* Analysis: Move llvm::getConstantRangeFromMetadata to IR library.Peter Collingbourne2016-10-212-0/+2
| | | | | | | | We're about to start using it there. Differential Revision: https://reviews.llvm.org/D25877 llvm-svn: 284865
* [StripGCRelocates] New pass to remove gc.relocates added by RS4GCAnna Thomas2016-10-213-0/+82
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Utility pass to remove gc.relocates created by rewrite statepoints for GC. With respect to safepoint verification, the IR generated would be incorrect, and cannot run as such. This would be a single transformation on the final optimized IR. The benefit of the pass is for easy analysis when the IRs are 'polluted' by too many gc.relocates. Added tests. test run: All RS4GC tests with -verify option. Local downstream tests on large IR files. This also works when the pointer being gc.relocated is another gc.relocate. Reviewers: sanjoy, reames Subscribers: beanz, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D25096 llvm-svn: 284855
* [LoopUnroll] Keep the loop test only on the first iteration of max-or-zero loopsJohn Brawn2016-10-212-16/+25
| | | | | | | | | | | | | | | | When we have a loop with a known upper bound on the number of iterations, and furthermore know that either the number of iterations will be either exactly that upper bound or zero, then we can fully unroll up to that upper bound keeping only the first loop test to check for the zero iteration case. Most of the work here is in plumbing this 'max-or-zero' information from the part of scalar evolution where it's detected through to loop unrolling. I've also gone for the safe default of 'false' everywhere but howManyLessThans which could probably be improved. Differential Revision: https://reviews.llvm.org/D25682 llvm-svn: 284818
* Revert "[GVN/PRE] Hoist global values outside of loops."Davide Italiano2016-10-211-58/+26
| | | | | | | | | There's no agreement about this patch. I personally find the PRE machinery of the current GVN hard enough to reason about that I'm not sure I'll try to land this again, instead of working on the rewrite). llvm-svn: 284796
* [MSSA] Avoid unnecessary use walks when calling getClobberingMemoryAccessDaniel Berlin2016-10-201-6/+37
| | | | | | | | | | | | | | | Summary: This allows us to mark when uses have been optimized. This lets us avoid rewalking (IE when people call getClobberingAccess on everything), and also enables us to later relax the requirement of use optimization during updates with less cost. Reviewers: george.burgess.iv Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D25172 llvm-svn: 284771
* [GVN] Use defaulted members. No functional change.Benjamin Kramer2016-10-201-10/+3
| | | | llvm-svn: 284726
* Do a sweep over move ctors and remove those that are identical to the default.Benjamin Kramer2016-10-201-20/+0
| | | | | | | | | | All of these existed because MSVC 2013 was unable to synthesize default move ctors. We recently dropped support for it so all that error-prone boilerplate can go. No functionality change intended. llvm-svn: 284721
* [IndVarSimplify] Teach calculatePostIncRange to take guards into accountArtur Pilipenko2016-10-191-2/+26
| | | | | | | | Reviewed By: sanjoy Differential Revision: https://reviews.llvm.org/D25739 llvm-svn: 284632
* [LV] Avoid emitting trivially dead instructionsMatthew Simpson2016-10-191-0/+45
| | | | | | | | | | | | | | | Some instructions from the original loop, when vectorized, can become trivially dead. This happens because of the way we structure the new loop. For example, we create new induction variables and induction variable "steps" in the new loop. Thus, when we go to vectorize the original induction variable update, it may no longer be needed due to the instructions we've already created. This patch prevents us from creating these redundant instructions. This reduces code size before simplification and allows greater flexibility in code generation since we have fewer unnecessary instruction uses. Differential Revision: https://reviews.llvm.org/D25631 llvm-svn: 284631
* [IndVarSimplify] Use control-dependent range information to prove non-negativityArtur Pilipenko2016-10-191-2/+148
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This change is motivated by the case when IndVarSimplify doesn't widen a comparison of IV increment because it can't prove IV increment being non-negative. We end up with a redundant trunc of the widened increment on this example. for.body: %i = phi i32 [ %start, %for.body.lr.ph ], [ %i.inc, %for.inc ] %within_limits = icmp ult i32 %i, 64 br i1 %within_limits, label %continue, label %for.end continue: %i.i64 = zext i32 %i to i64 %arrayidx = getelementptr inbounds i32, i32* %base, i64 %i.i64 %val = load i32, i32* %arrayidx, align 4 br label %for.inc for.inc: %i.inc = add nsw nuw i32 %i, 1 %cmp = icmp slt i32 %i.inc, %limit br i1 %cmp, label %for.body, label %for.end There is a range check inside of the loop which guarantees the IV to be non-negative. NSW on the increment guarantees that the increment is also non-negative. Teach IndVarSimplify to use the range check to prove non-negativity of loop increments. Reviewed By: sanjoy Differential Revision: https://reviews.llvm.org/D25738 llvm-svn: 284629
* [asan] Replace std::to_string with llvm::to_stringVitaly Buka2016-10-191-1/+2
| | | | llvm-svn: 284557
* [asan] Simplify calculation of stack frame layout extraction calculation of ↵Vitaly Buka2016-10-182-52/+48
| | | | | | | | | | | | stack description into separate function. Reviewers: eugenis Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D25754 llvm-svn: 284547
* [asan] Append line number to variable name if line is available and in the ↵Vitaly Buka2016-10-182-12/+27
| | | | | | | | | | | | same file as the function. PR30498 Reviewers: eugenis Differential Revision: https://reviews.llvm.org/D25715 llvm-svn: 284546
* Conditionally eliminate library calls where the result value is not usedRong Xu2016-10-184-0/+573
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This pass shrink-wraps a condition to some library calls where the call result is not used. For example: sqrt(val); is transformed to if (val < 0) sqrt(val); Even if the result of library call is not being used, the compiler cannot safely delete the call because the function can set errno on error conditions. Note in many functions, the error condition solely depends on the incoming parameter. In this optimization, we can generate the condition can lead to the errno to shrink-wrap the call. Since the chances of hitting the error condition is low, the runtime call is effectively eliminated. These partially dead calls are usually results of C++ abstraction penalty exposed by inlining. This optimization hits 108 times in 19 C/C++ programs in SPEC2006. Reviewers: hfinkel, mehdi_amini, davidxl Subscribers: modocache, mgorny, mehdi_amini, xur, llvm-commits, beanz Differential Revision: https://reviews.llvm.org/D24414 llvm-svn: 284542
* [GVN] Consistently use division instead of shift. NFCI.Davide Italiano2016-10-181-2/+2
| | | | | | | This is in line with other places of GVN (e.g. load coercion logic). llvm-svn: 284535
* [GVN] Remove dead code. NFC.Davide Italiano2016-10-181-20/+1
| | | | llvm-svn: 284534
* [esan] Remove global variable.Benjamin Kramer2016-10-181-1/+2
| | | | | | It's not thread safe and completely unnecessary. llvm-svn: 284520
* [asan] Make -asan-experimental-poisoning the only behaviorVitaly Buka2016-10-181-34/+11
| | | | | | | | | | Reviewers: eugenis Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D25735 llvm-svn: 284505
* Ignore debug info when making optimization decisions in SimplifyCFG.Dehao Chen2016-10-171-11/+18
| | | | | | | | | | | | Summary: Debug info should *not* affect code generation. This patch properly handles debug info to make sure the generated code are the same with or without debug info. Reviewers: davidxl, mzolotukhin, jmolloy Subscribers: aprantl, llvm-commits Differential Revision: https://reviews.llvm.org/D25286 llvm-svn: 284415
* [SimplifyCFG] Don't lower complex ConstantExprs to lookup tablesOliver Stannard2016-10-171-1/+4
| | | | | | | | | | Not all ConstantExprs can be represented by a global variable, for example most pointer arithmetic other than addition of a constant, so we can't convert these values from switch statements to lookup tables. Differential Revision: https://reviews.llvm.org/D25550 llvm-svn: 284379
* [GVN/PRE] Hoist global values outside of loops.Davide Italiano2016-10-151-26/+58
| | | | | | | | | | | In theory this could be generalized to move anything where we prove the operands are available, but that would require rewriting PRE. As NewGVN will hopefully come soon, and we're trying to rewrite PRE in terms of NewGVN+MemorySSA, it's probably not worth spending too much time on it. Fix provided by Daniel Berlin! llvm-svn: 284311
* [SimplifyCFG] Use the error checking provided by getPrevNode.Benjamin Kramer2016-10-151-7/+11
| | | | | | | | | BasicBlock::size is O(insts), making this loop O(blocks*insts), which can be really slow on generated code. getPrevNode already checks if we're at the beginning of the block and returns nullptr if so, just use that instead. No functionality change intended. llvm-svn: 284303
* [NFC] Loop Versioning for LICM code clean upEvgeny Astigeevich2016-10-141-31/+42
| | | | | | | | | | | | - Removed unused class members. - Made class internal data private. - Made class scoped data function scoped where it's possible. - Replace naked new/delete with unique_ptr. - Made resources guaranteed to be freed. Differential Revision: https://reviews.llvm.org/D25464 llvm-svn: 284290
* [InstCombine] use m_APInt to allow sub with constant folds for splat vectorsSanjay Patel2016-10-141-18/+19
| | | | llvm-svn: 284247
* [InstCombine] sub X, sext(bool Y) -> add X, zext(bool Y)Sanjay Patel2016-10-141-0/+11
| | | | | | | | | | | | Prefer add/zext because they are better supported in terms of value-tracking. Note that the backend should be prepared for this IR canonicalization (including vector types) after: https://reviews.llvm.org/rL284015 Differential Revision: https://reviews.llvm.org/D25135 llvm-svn: 284241
* [LV] Account for predicated stores in instruction costsMatthew Simpson2016-10-131-0/+6
| | | | | | | This patch ensures that we scale the estimated cost of predicated stores by block probability. This is a follow-on patch for r284123. llvm-svn: 284126
* [LV] Avoid rounding errors for predicated instruction costsMatthew Simpson2016-10-131-26/+29
| | | | | | | | | | | | This patch modifies the cost calculation of predicated instructions (div and rem) to avoid the accumulation of rounding errors due to multiple truncating integer divisions. The calculation for predicated stores will be addressed in a follow-on patch since we currently don't scale the cost of predicated stores by block probability. Differential Revision: https://reviews.llvm.org/D25333 llvm-svn: 284123
* Memory-SSA: strengthen defClobbersUseOrDef interfaceSebastian Pop2016-10-131-19/+15
| | | | | | | As Danny pointed out, defClobbersUseOrDef should use MemoryLocOrCall to make sure fences are properly handled. llvm-svn: 284099
* commit back "GVN-hoist: fix store past load dependence analysis (PR30216, ↵Sebastian Pop2016-10-132-90/+109
| | | | | | | | | | PR30499)" This is with an extra change to avoid calling MemoryLocation::get() on a call instruction. Differential Revision: https://reviews.llvm.org/D25542 llvm-svn: 284098
* Revert "GVN-hoist: fix store past load dependence analysis (PR30216, PR30499)"Reid Kleckner2016-10-132-104/+90
| | | | | | | | | | | This CL didn't actually address the test case in PR30499, and clang still crashes. Also revert dependent change "Memory-SSA cleanup of clobbers interface, NFC" Reverts r283965 and r283967. llvm-svn: 284093
* Reapply "[LoopUnroll] Use the upper bound of the loop trip count to fullly ↵Haicheng Wu2016-10-122-36/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | unroll a loop" Reappy r284044 after revert in r284051. Krzysztof fixed the error in r284049. The original summary: This patch tries to fully unroll loops having break statement like this for (int i = 0; i < 8; i++) { if (a[i] == value) { found = true; break; } } GCC can fully unroll such loops, but currently LLVM cannot because LLVM only supports loops having exact constant trip counts. The upper bound of the trip count can be obtained from calling ScalarEvolution::getMaxBackedgeTakenCount(). Part of the patch is the refactoring work in SCEV to prevent duplicating code. The feature of using the upper bound is enabled under the same circumstance when runtime unrolling is enabled since both are used to unroll loops without knowing the exact constant trip count. llvm-svn: 284053
* Revert "[LoopUnroll] Use the upper bound of the loop trip count to fullly ↵Haicheng Wu2016-10-122-91/+36
| | | | | | | | unroll a loop" This reverts commit r284044. llvm-svn: 284051
* [LoopUnroll] Use the upper bound of the loop trip count to fullly unroll a loopHaicheng Wu2016-10-122-36/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch tries to fully unroll loops having break statement like this for (int i = 0; i < 8; i++) { if (a[i] == value) { found = true; break; } } GCC can fully unroll such loops, but currently LLVM cannot because LLVM only supports loops having exact constant trip counts. The upper bound of the trip count can be obtained from calling ScalarEvolution::getMaxBackedgeTakenCount(). Part of the patch is the refactoring work in SCEV to prevent duplicating code. The feature of using the upper bound is enabled under the same circumstance when runtime unrolling is enabled since both are used to unroll loops without knowing the exact constant trip count. Differential Revision: https://reviews.llvm.org/D24790 llvm-svn: 284044
* [SimplifyCFG] Don't create PHI nodes for constant bundle operandsSanjoy Das2016-10-121-1/+10
| | | | | | | | | | | | | | | | | | | | Summary: Constant bundle operands may need to retain their constant-ness for correctness. I'll admit that this is slightly odd, but it looks like SimplifyCFG already does this for things like @llvm.frameaddress and @llvm.stackmap, so I suppose adding one more case is not a big deal. It is possible to add a mechanism to denote bundle operands that need to remain constants, but that's probably too complicated for the time being. Reviewers: jmolloy Subscribers: mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D25502 llvm-svn: 284028
* [CVP] Convert an AShr to a LShr if 1st operand is known to be nonnegative.Chad Rosier2016-10-121-0/+23
| | | | | | | | | | | | | | An arithmetic shift can be safely changed to a logical shift if the first operand is known positive. This allows ComputeKnownBits (and similar analysis) to determine the sign bit of the shifted value in some cases. In turn, this allows InstCombine to canonicalize a signed comparison (a > 0) into an equality check (a != 0). PR30577 Differential Revision: https://reviews.llvm.org/D25119 llvm-svn: 284013
* [InstCombine] Fix constexpr issue in select combiningSimon Pilgrim2016-10-121-4/+5
| | | | | | | | As discussed by Andrea on PR30486, we have an unsafe cast to an Instruction type in the select combine which doesn't take into account that it could be a ConstantExpr instead. Differential Revision: https://reviews.llvm.org/D25466 llvm-svn: 284000
* Memory-SSA cleanup of clobbers interface, NFCSebastian Pop2016-10-122-19/+26
| | | | | | | | | This implements the cleanup that Danny asked to commit separately from the previous fix to GVN-hoist in https://reviews.llvm.org/D25476#inline-219818 Tested with ninja check on x86_64-linux. llvm-svn: 283967
* GVN-hoist: fix store past load dependence analysis (PR30216, PR30499)Sebastian Pop2016-10-122-81/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a refreshed version of a patch that was reverted: it fixes the problems reported in both PR30216 and PR30499, and contains all the test-cases from both bugs. To hoist stores past loads, we used to search for potential conflicting loads on the hoisting path by following a MemorySSA def-def link from the store to be hoisted to the previous defining memory access, and from there we followed the def-use chains to all the uses that occur on the hoisting path. The problem is that the def-def link may point to a store that does not alias with the store to be hoisted, and so the loads that are walked may not alias with the store to be hoisted, and even as in the testcase of PR30216, the loads that may alias with the store to be hoisted are not visited. The current patch visits all loads on the path from the store to be hoisted to the hoisting position and uses the alias analysis to ask whether the store may alias the load. I was not able to use the MemorySSA functionality to ask for whether load and store are clobbered: I'm not sure which function to call, so I used a call to AA->isNoAlias(). Store past store is still working as before using a MemorySSA query: I added an extra test to pr30216.ll to make sure store past store does not regress. Tested on x86_64-linux with check and a test-suite run. Differential Revision: https://reviews.llvm.org/D25476 llvm-svn: 283965
* [sanitizer-coverage] use private linkage for coverage guards, delete old ↵Kostya Serebryany2016-10-111-12/+4
| | | | | | commented-out code. llvm-svn: 283924
* [LCSSA] Implement linear algorithm for the isRecursivelyLCSSAFormIgor Laevsky2016-10-113-9/+13
| | | | | | | | For each block check that it doesn't have any uses outside of it's innermost loop. Differential Revision: https://reviews.llvm.org/D25364 llvm-svn: 283877
* [InstCombine] Transform !range metadata to !nonnull when combining loadsDavid Majnemer2016-10-111-2/+10
| | | | | | | | | | | | When combining an integer load with !range metadata that does not include 0 to a pointer load, make sure emit !nonnull metadata on the newly-created pointer load. This prevents the !nonnull metadata from being dropped during a ptrtoint/inttoptr pair. This fixes PR30597. Patch by Ariel Ben-Yehuda! Differential Revision: https://reviews.llvm.org/D25215 llvm-svn: 283836
OpenPOWER on IntegriCloud