summaryrefslogtreecommitdiffstats
path: root/llvm/test/Transforms
Commit message (Collapse)AuthorAgeFilesLines
* Revert "Reapply commit r258404 with fix."David Majnemer2016-02-171-18/+13
| | | | | | This reverts commit r259357, it caused PR26629. llvm-svn: 261137
* [ObjCARC] Handle ARCInstKind::ClaimRV in OptimizeIndividualCalls.Frederic Riss2016-02-171-0/+47
| | | | | | | | | When support for objc_unsafeClaimAutoreleasedReturnValue has been added to the ARC optimizer in r258970, one case was missed which would lead the optimizer to execute an llvm_unreachable. In this case, just handle ClaimRV in the same way we handle RetainRV. llvm-svn: 261134
* [AliasSetTracker] Teach AliasSetTracker about MemSetInstHaicheng Wu2016-02-171-0/+51
| | | | | | | This change is to fix the problem discussed in http://lists.llvm.org/pipermail/llvm-dev/2016-February/095446.html. llvm-svn: 261052
* Revert 260705, it appears to be causing pr26628Philip Reames2016-02-161-55/+0
| | | | | | The root issue appears to be a confusion around what makeNoWrapRegion actually does. It seems likely we need two versions of this function with slightly different semantics. llvm-svn: 260981
* [SCEVExpander] Make findExistingExpansion smarterJunmo Park2016-02-161-0/+34
| | | | | | | | | | | | | Summary: Extending findExistingExpansion can use existing value in ExprValueMap. This patch gives 0.3~0.5% performance improvements on benchmarks(test-suite, spec2000, spec2006, commercial benchmark) Reviewers: mzolotukhin, sanjoy, zzheng Differential Revision: http://reviews.llvm.org/D15559 llvm-svn: 260938
* [LV] Add support for insertelt/extractelt processing during type truncationSilviu Baranga2016-02-151-0/+47
| | | | | | | | | | | | | | | | | | Summary: While shrinking types according to the required bits, we can encounter insert/extract element instructions. This will cause us to reach an llvm_unreachable statement. This change adds support for truncating insert/extract element operations, and adds a regression test. Reviewers: jmolloy Subscribers: mzolotukhin, llvm-commits Differential Revision: http://reviews.llvm.org/D17078 llvm-svn: 260893
* [attrs] Move the norecurse deduction to operate on the node set ratherChandler Carruth2016-02-132-3/+8
| | | | | | | | | | | | | | | | | | than the SCC object, and have it scan the instruction stream directly rather than relying on call records. This makes the behavior of this routine consistent between libc routines and LLVM intrinsics for libc routines. We can go and start teaching it about those being norecurse, but we should behave the same for the intrinsic and the libc routine rather than differently. I chatted with James Molloy and the inconsistency doesn't seem intentional and likely is due to intrinsic calls not being modelled in the call graph analyses. This also fixes a bug where we would deduce norecurse on optnone functions, when generally we try to handle optnone functions as-if they were replaceable and thus unanalyzable. llvm-svn: 260813
* [LIR] Allow merging of memsets in negatively strided loops.Chad Rosier2016-02-121-0/+33
| | | | | | Last part of PR25166. llvm-svn: 260732
* [SimplifyCFG] Don't fold conditional branches that contain calls to ↵Justin Lebar2016-02-121-0/+28
| | | | | | | | | | | | | | | | convergent functions. Summary: Performing this optimization duplicates the call to the convergent function and adds new control-flow dependencies, which is a no-no. Reviewers: jingyue Subscribers: broune, hfinkel, tra, resistor, joker.eph, arsenm, llvm-commits, mzolotukhin Differential Revision: http://reviews.llvm.org/D17128 llvm-svn: 260730
* [LoopRotate] Don't perform loop rotation if the loop header calls a ↵Justin Lebar2016-02-121-0/+31
| | | | | | | | | | | | | | | | | convergent function. Summary: Calls to convergent functions can be duplicated, but only if the duplicates are not control-flow dependent on any additional values. Loop rotation doesn't meet the bar. Reviewers: jingyue Subscribers: mzolotukhin, llvm-commits, arsenm, joker.eph, resistor, tra, hfinkel, broune Differential Revision: http://reviews.llvm.org/D17127 llvm-svn: 260729
* [LVI] Exploit nsw/nuw when computing constant rangesPhilip Reames2016-02-121-0/+55
| | | | | | | | | | As the title says. Modelled after similar code in SCEV. This is useful when analysing induction variables in loops which have been canonicalized by other passes. I wrote the tests as non-loops specifically to avoid the generality introduced in http://reviews.llvm.org/D17174. While that can handle many induction variables without *needing* to exploit nsw, there's no reason not to use it if we've already proven it. Differential Revision: http://reviews.llvm.org/D17177 llvm-svn: 260705
* [InstCombine] Don't aggressively replace xor with icmpDavid Majnemer2016-02-121-0/+41
| | | | | | | | | | | | | | | | | | For some cases, InstCombine replaces the sequence of xor/sub instruction followed by cmp instruction into a single cmp instruction. However, this replacement may result suboptimal result especially when the xor/sub has more than one use, as discussed in bug 26465 (https://llvm.org/bugs/show_bug.cgi?id=26465). This patch make the replacement happen only when xor/sub has only one use. Differential Revision: http://reviews.llvm.org/D16915 Patch by Taewook Oh! llvm-svn: 260695
* [LVI] Improve select handling to use conditionPhilip Reames2016-02-121-0/+49
| | | | | | | | | | This patches teaches LVI to recognize clamp idioms (e.g. select(a > 5, a, 5) will always produce something greater than 5. The tests end up being somewhat simplistic because trying to exercise the case I actually care about (a loop with a range check on a clamped secondary induction variable) ends up tripping across a couple of other imprecisions in the analysis. Ah, the joys of LVI... Differential Revision: http://reviews.llvm.org/D16827 llvm-svn: 260627
* Re-apply r238452, the bug was in clang and was fixed in r260567.Quentin Colombet2016-02-113-2/+159
| | | | | | | | | | | | | | | | Original commit message: [InstCombine] Fold IntToPtr and PtrToInt into preceding loads. Currently we only fold a BitCast into a Load when the BitCast is its only user. Do the same for any no-op cast. Patch by Philip Pfaffe! Differential Revision: http://reviews.llvm.org/D9152 llvm-svn: 260612
* Set load alignment on aggregate loads.Pete Cooper2016-02-111-0/+15
| | | | | | | | | | | | | | | | When optimizing a extractvalue(load), we generate a load from the aggregate type. This load didn't have alignment set and so would get the alignment of the type. This breaks when the type is packed and so the alignment should be lower. For example, loading { int, int } would give us alignment of 4, but the original load from this type may have an alignment of 1 if packed. Reviewed by David Majnemer Differential revision: http://reviews.llvm.org/D17158 llvm-svn: 260587
* Add a test case to show isKnownNonZero() returns correctly; NFCJun Bum Lim2016-02-111-0/+15
| | | | | | | | | | | | | | Summary: Added a test case just to make sure that isKnownNonZero() returns false when we cannot guarantee that a ConstantExpr is a non-zero constant. Reviewers: sanjoy, majnemer, mcrosier, nlewycky Subscribers: nlewycky, mssimpso, mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D16908 llvm-svn: 260544
* [InstCombine] Simplify a known nonzero incoming value of PHIJun Bum Lim2016-02-111-0/+95
| | | | | | | | | | | | | | | | | | | | Summary: When a PHI is used only to be compared with zero, it is possible to replace an incoming value with any non-zero constant if the incoming value can be proved as a known nonzero value. For example, in below code, we can replace the incoming value %v with any non-zero constant based on the fact that the PHI is only used to be compared with zero and %v is a known non-zero value: %v = select %cond, 1, 2 %p = phi [%v, BB] ... %c = icmp eq, %p, 0 Reviewers: mcrosier, jmolloy, sanjoy Subscribers: hfinkel, mcrosier, majnemer, llvm-commits, haicheng, bmakam, mssimpso, gberry Differential Revision: http://reviews.llvm.org/D16240 llvm-svn: 260530
* Don't propagate dereferenceable attribute through gc.relocate in InstCombineArtur Pilipenko2016-02-111-11/+0
| | | | | | | | Reviewed By: reames Differential Revision: http://reviews.llvm.org/D16143 llvm-svn: 260509
* AMDGPU: Remove some old intrinsic uses from testsMatt Arsenault2016-02-113-19/+8
| | | | llvm-svn: 260493
* FunctionImport: add a progressive heuristic to limit importing too deep in ↵Mehdi Amini2016-02-102-0/+68
| | | | | | | | | | | | | | | | | | | | the callgraph The current function importer will walk the callgraph, importing transitively any callee that is below the threshold. This can lead to import very deep which is costly in compile time and not necessarily beneficial as most of the inline would happen in imported function and not necessarilly in user code. The actual factor has been carefully chosen by flipping a coin ;) Some tuning need to be done (just at the existing limiting threshold). Reviewers: tejohnson Differential Revision: http://reviews.llvm.org/D17082 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 260466
* [PGO] Indirect-call profile annotation in IR level profilingRong Xu2016-02-102-0/+78
| | | | | | | | | | This patch reads the indirect-call value records in the profile and makes the annotation in the indirect-call instruction. This is for IR level profile instrumentation. Differential Revision: http://reviews.llvm.org/D16935 llvm-svn: 260400
* [PGO] Differentiate Clang instrumentation and IR level instrumentation profilesRong Xu2016-02-1018-1/+53
| | | | | | | | | | | | | | | | | | | | This patch uses one bit in profile version to differentiate Clang instrumentation and IR level instrumentation profiles. PGOInstrumenation generates a COMDAT variable __llvm_profile_raw_version so that the compiler runtime can set the right profile kind. For Maco-O platform, we generate the variable as linkonce_odr linkage as COMDAT is not supported. PGOInstrumenation now checks this bit to make sure it's an IR level instrumentation profile. The patch was submitted as r260164 but reverted due to a Darwin test breakage. Original Differential Revision: http://reviews.llvm.org/D15540 Differential Revision: http://reviews.llvm.org/D17020 llvm-svn: 260385
* Add convergent-removing bits to FunctionAttrs pass.Justin Lebar2016-02-091-0/+94
| | | | | | | | | | | | | | | | | Summary: Remove the convergent attribute on any functions which provably do not contain or invoke any convergent functions. After this change, we'll be able to modify clang to conservatively add 'convergent' to all functions when compiling CUDA. Reviewers: jingyue, joker.eph Subscribers: llvm-commits, tra, jhen, hfinkel, resistor, chandlerc, arsenm Differential Revision: http://reviews.llvm.org/D17013 llvm-svn: 260319
* WholeProgramDevirt: introduce.Peter Collingbourne2016-02-0916-0/+904
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This pass implements whole program optimization of virtual calls in cases where we know (via bitset information) that the list of callees is fixed. This includes the following: - Single implementation devirtualization: if a virtual call has a single possible callee, replace all calls with a direct call to that callee. - Virtual constant propagation: if the virtual function's return type is an integer <=64 bits and all possible callees are readnone, for each class and each list of constant arguments: evaluate the function, store the return value alongside the virtual table, and rewrite each virtual call as a load from the virtual table. - Uniform return value optimization: if the conditions for virtual constant propagation hold and each function returns the same constant value, replace each virtual call with that constant. - Unique return value optimization for i1 return values: if the conditions for virtual constant propagation hold and a single vtable's function returns 0, or a single vtable's function returns 1, replace each virtual call with a comparison of the vptr against that vtable's address. Differential Revision: http://reviews.llvm.org/D16795 llvm-svn: 260312
* [InstCombine][GC] Handle gc.relocations of vector typePhilip Reames2016-02-091-0/+18
| | | | | | | | We introduced gc.relocates of vector-of-pointer types a couple of weeks back. Somehow, I missed updating the InstCombine rule to account for this. If we hit this code path with a vector-of-pointers gc.relocate, we'd crash on a cast<PointerType>. I also took the chance to do a bit of code style cleanup. llvm-svn: 260279
* [FunctionAttrs] Fix SCC logic around operand bundlesSanjoy Das2016-02-091-0/+13
| | | | | | | | | | | FunctionAttrs does an "optimistic" analysis of SCCs as a unit, which means normally it is able to disregard calls from an SCC into itself. However, calls and invokes with operand bundles are allowed to have memory effects not fully described by the memory effects on the call target, so we can't be optimistic around operand-bundled calls from an SCC into itself. llvm-svn: 260244
* [PGO] Revert r260146 as it breaks Darwin platforms.Rong Xu2016-02-0818-49/+0
| | | | | | | r260146 | xur | 2016-02-08 13:07:46 -0800 (Mon, 08 Feb 2016) | 13 lines [PGO] Differentiate Clang instrumentation and IR level instrumentation profiles llvm-svn: 260170
* [PGO] Differentiate Clang instrumentation and IR level instrumentation profilesRong Xu2016-02-0818-0/+49
| | | | | | | | | | | | | | This patch uses one bit in profile version to differentiate Clang instrumentation and IR level instrumentation profiles. PGOInstrumenation generates a COMDAT variable __llvm_profile_raw_version so that the compiler runtime can set the right profile kind. PGOInstrumenation now checks this bit to make sure it's an IR level instrumentation profile. Differential Revision: http://reviews.llvm.org/D15540 llvm-svn: 260146
* [SCEV][LAA] Re-commit r260085 and r260086, this time with a fix for the memorySilviu Baranga2016-02-081-6/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | sanitizer issue. The PredicatedScalarEvolution's copy constructor wasn't copying the Generation value, and was leaving it un-initialized. Original commit message: [SCEV][LAA] Add no wrap SCEV predicates and use use them to improve strided pointer detection Summary: This change adds no wrap SCEV predicates with: - support for runtime checking - support for expression rewriting: (sext ({x,+,y}) -> {sext(x),+,sext(y)} (zext ({x,+,y}) -> {zext(x),+,sext(y)} Note that we are sign extending the increment of the SCEV, even for the zext case. This is needed to cover the fairly common case where y would be a (small) negative integer. In order to do this, this change adds two new flags: nusw and nssw that are applicable to AddRecExprs and permit the transformations above. We also change isStridedPtr in LAA to be able to make use of these predicates. With this feature we should now always be able to work around overflow issues in the dependence analysis. Reviewers: mzolotukhin, sanjoy, anemet Subscribers: mzolotukhin, sanjoy, llvm-commits, rengolin, jmolloy, hfinkel Differential Revision: http://reviews.llvm.org/D15412 llvm-svn: 260112
* Revert r260086 and r260085. They have broken the memorySilviu Baranga2016-02-081-4/+6
| | | | | | sanitizer bots. llvm-svn: 260087
* [SCEV][LAA] Add no wrap SCEV predicates and use use them to improve strided ↵Silviu Baranga2016-02-081-6/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | pointer detection Summary: This change adds no wrap SCEV predicates with: - support for runtime checking - support for expression rewriting: (sext ({x,+,y}) -> {sext(x),+,sext(y)} (zext ({x,+,y}) -> {zext(x),+,sext(y)} Note that we are sign extending the increment of the SCEV, even for the zext case. This is needed to cover the fairly common case where y would be a (small) negative integer. In order to do this, this change adds two new flags: nusw and nssw that are applicable to AddRecExprs and permit the transformations above. We also change isStridedPtr in LAA to be able to make use of these predicates. With this feature we should now always be able to work around overflow issues in the dependence analysis. Reviewers: mzolotukhin, sanjoy, anemet Subscribers: mzolotukhin, sanjoy, llvm-commits, rengolin, jmolloy, hfinkel Differential Revision: http://reviews.llvm.org/D15412 llvm-svn: 260085
* Make check line consistentDaniel Berlin2016-02-071-0/+29
| | | | llvm-svn: 260055
* Corrected tests for Loop Versioning LICM, by adding “REQUIRES: asserts”.Ashutosh Nema2016-02-063-0/+3
| | | | | | Earlier they were failing under no-assert build. llvm-svn: 259989
* New Loop Versioning LICM PassAshutosh Nema2016-02-063-0/+161
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When alias analysis is uncertain about the aliasing between any two accesses, it will return MayAlias. This uncertainty from alias analysis restricts LICM from proceeding further. In cases where alias analysis is uncertain we might use loop versioning as an alternative. Loop Versioning will create a version of the loop with aggressive aliasing assumptions in addition to the original with conservative (default) aliasing assumptions. The version of the loop making aggressive aliasing assumptions will have all the memory accesses marked as no-alias. These two versions of loop will be preceded by a memory runtime check. This runtime check consists of bound checks for all unique memory accessed in loop, and it ensures the lack of memory aliasing. The result of the runtime check determines which of the loop versions is executed: If the runtime check detects any memory aliasing, then the original loop is executed. Otherwise, the version with aggressive aliasing assumptions is used. The pass is off by default and can be enabled with command line option -enable-loop-versioning-licm. Reviewers: hfinkel, anemet, chatur01, reames Subscribers: MatzeB, grosser, joker.eph, sanjoy, javed.absar, sbaranga, llvm-commits Differential Revision: http://reviews.llvm.org/D9151 llvm-svn: 259986
* [LoopLoadElim] Don't allow versioning when optForSizeAdam Nemet2016-02-051-0/+76
| | | | | | This was requested in the review of D16300. llvm-svn: 259861
* Fix typo in commentAdam Nemet2016-02-051-1/+1
| | | | llvm-svn: 259860
* Add a test for MemorySSA. NFC.George Burgess IV2016-02-051-0/+24
| | | | | | | We don't currently have many tests that deal with operations on multiple local MemoryLocations. This new test helps out a bit in that regard. llvm-svn: 259854
* The canonical way to XFAIL a test for all targets is XFAIL: *, not XFAIL:Benjamin Kramer2016-02-041-1/+1
| | | | | | | | Fix the lit bug that enabled this "feature" (empty triple is substring of all possible target triples) and change the two outliers to use the documented * syntax. llvm-svn: 259799
* [SCEV] Try to reuse existing value during SCEV expansionWei Mi2016-02-046-20/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Current SCEV expansion will expand SCEV as a sequence of operations and doesn't utilize the value already existed. This will introduce redundent computation which may not be cleaned up throughly by following optimizations. This patch introduces an ExprValueMap which is a map from SCEV to the set of equal values with the same SCEV. When a SCEV is expanded, the set of values is checked and reused whenever possible before generating a sequence of operations. The original commit triggered regressions in Polly tests. The regressions exposed two problems which have been fixed in current version. 1. Polly will generate a new function based on the old one. To generate an instruction for the new function, it builds SCEV for the old instruction, applies some tranformation on the SCEV generated, then expands the transformed SCEV and insert the expanded value into new function. Because SCEV expansion may reuse value cached in ExprValueMap, the value in old function may be inserted into new function, which is wrong. In SCEVExpander::expand, there is a logic to check the cached value to be used should dominate the insertion point. However, for the above case, the check always passes. That is because the insertion point is in a new function, which is unreachable from the old function. However for unreachable node, DominatorTreeBase::dominates thinks it will be dominated by any other node. The fix is to simply add a check that the cached value to be used in expansion should be in the same function as the insertion point instruction. 2. When the SCEV is of scConstant type, expanding it directly is cheaper than reusing a normal value cached. Although in the cached value set in ExprValueMap, there is a Constant type value, but it is not easy to find it out -- the cached Value set is not sorted according to the potential cost. Existing reuse logic in SCEVExpander::expand simply chooses the first legal element from the cached value set. The fix is that when the SCEV is of scConstant type, don't try the reuse logic. simply expand it. Differential Revision: http://reviews.llvm.org/D12090 llvm-svn: 259736
* [SimplifyCFG] Fix for "endless" loop after dead code removal (Alternative toGerolf Hoflehner2016-02-031-0/+101
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | D16251) Summary: This is a simpler fix to the problem than the dominator approach in http://reviews.llvm.org/D16251. It adds only values into the gather() while loop that have been seen before. The actual endless loop is in the constant compare gather() routine in Utils/SimplifyCFG.cpp. The same value ret.0.off0.i is pushed back into the queue: %.ret.0.off0.i = or i1 %.ret.0.off0.i, %cmp10.i Here is what happens at the IR level: for.cond.i: ; preds = %if.end6.i, %if.end.i54 %ix.0.i = phi i32 [ 0, %if.end.i54 ], [ %inc.i55, %if.end6.i ] %ret.0.off0.i = phi i1 [false, %if.end.i54], [%.ret.0.off0.i, %if.end6.i] <<< %cmp2.i = icmp ult i32 %ix.0.i, %11 br i1 %cmp2.i, label %for.body.i, label %LBJ_TmpSimpleNeedExt.exit if.end6.i: ; preds = %for.body.i %cmp10.i = icmp ugt i32 %conv.i, %add9.i %.ret.0.off0.i = or i1 %ret.0.off0.i, %cmp10.i <<< When if.end.i54 gets eliminated which removes the definition of ret.0.off0.i. The result is the expression %.ret.0.off0.i = or i1 %.ret.0.off0.i, %cmp10.i (Note the first ‘or’ operand is now %.ret.0.off0.i, and *NOT* %ret.0.off0.i). And now there is use of .ret.0.off0.i before a definition which triggers the “endless” loop in gather(): while(!DFT.empty()) { V = DFT.pop_back_val(); // V is .ret.0.off0.i if (Instruction *I = dyn_cast<Instruction>(V)) { // If it is a || (or && depending on isEQ), process the operands. if (I->getOpcode() == (isEQ ? Instruction::Or : Instruction::And)) { DFT.push_back(I->getOperand(1)); // This is now .ret.0.off0.i also DFT.push_back(I->getOperand(0)); continue; // “endless loop” for .ret.0.off0.i } Reviewers: reames, ahatanak Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D16839 llvm-svn: 259730
* [LoopStrengthReduce] Don't rewrite PHIs with incoming values from CatchSwitchesDavid Majnemer2016-02-031-0/+29
| | | | | | | | | | Bail out if we have a PHI on an EHPad that gets a value from a CatchSwitchInst. Because the CatchSwitchInst cannot be split, there is no good place to stick any instructions. This fixes PR26373. llvm-svn: 259702
* Revert r259662, which caused regressions on polly tests.Wei Mi2016-02-036-11/+20
| | | | llvm-svn: 259675
* [InstCombine] Revert r238452: Fold IntToPtr and PtrToInt into preceding loads.Quentin Colombet2016-02-033-159/+2
| | | | | | | | | | | | | | | | | | | | | | | | | According to git bisect, this is the root cause of a miscompile for Regex in libLLVMSupport. I am still working on reducing a test case. The actual bug may be elsewhere and this commit just exposed it. Anyway, at the moment, to reproduce, follow these steps: 1. Build clang and libLTO in release mode. 2. Create a new build directory <stage2> and cd into it. 3. Use clang and libLTO from #1 to build llvm-extract in Release mode + asserts using -O2 -flto 4. Run llvm-extract -ralias '.*bar' -S test/Other/extract-alias.ll Result: program doesn't contain global named '.*bar'! Expected result: @a0a0bar = alias void ()* @bar @a0bar = alias void ()* @bar declare void @bar() Note: In step #3, if you don't use lto or asserts, the miscompile disappears. llvm-svn: 259674
* [SCEV] Try to reuse existing value during SCEV expansionWei Mi2016-02-036-20/+11
| | | | | | | | | | | | | | | | Current SCEV expansion will expand SCEV as a sequence of operations and doesn't utilize the value already existed. This will introduce redundent computation which may not be cleaned up throughly by following optimizations. This patch introduces an ExprValueMap which is a map from SCEV to the set of equal values with the same SCEV. When a SCEV is expanded, the set of values is checked and reused whenever possible before generating a sequence of operations. Differential Revision: http://reviews.llvm.org/D12090 llvm-svn: 259662
* [DemandedBits] Revert r249687 due to PR26071James Molloy2016-02-031-34/+0
| | | | | | | | | | | | | | This regresses a test in LoopVectorize, so I'll need to go away and think about how to solve this in a way that isn't broken. From the writeup in PR26071: What's happening is that ComputeKnownZeroes is telling us that all bits except the LSB are zero. We're then deciding that only the LSB needs to be demanded from the icmp's inputs. This is where we're wrong - we're assuming that after simplification the bits that were known zero will continue to be known zero. But they're not - during trivialization the upper bits get changed (because an XOR isn't shrunk), so the icmp fails. The fault is in demandedbits - its contract does clearly state that a non-demanded bit may either be zero or one. llvm-svn: 259649
* [LoopVersioning] Expose loop versioning as a pass tooAdam Nemet2016-02-031-0/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: LoopVersioning is a transform utility that transform passes can use to run-time disambiguate may-aliasing accesses. I'd like to also expose as pass to allow it to be unit-tested. I am planning to add support for non-aliasing annotation in LoopVersioning and I'd like to be able to write tests directly using this pass. (After that feature is done, the pass could also be used to look for optimization opportunities that are hidden behind incomplete alias information at compile time.) The pass drives LoopVersioning in its default way which is to fully disambiguate may-aliasing accesses no matter how many checks are required. Reviewers: hfinkel, ashutosh.nema, sbaranga Subscribers: zzheng, mssimpso, llvm-commits, sanjoy Differential Revision: http://reviews.llvm.org/D16612 llvm-svn: 259610
* This patch adds MemorySSA to LLVM.George Burgess IV2016-02-0212-0/+502
| | | | | | | | | Please see include/llvm/Transforms/Utils/MemorySSA.h for a description of MemorySSA, and what it does. Differential Revision: http://reviews.llvm.org/D7864 llvm-svn: 259595
* [LVI] Introduce an intersect operation on lattice valuesPhilip Reames2016-02-022-0/+75
| | | | | | | | | | | | LVI has several separate sources of facts - edge local conditions, recursive queries, assumes, and control independent value facts - which all apply to the same value at the same location. The existing implementation was very conservative about exploiting all of these facts at once. This change introduces an "intersect" function specifically to abstract the action of picking a good set of facts from all of the separate facts given. At the moment, this function is relatively simple (i.e. mostly just reuses the bits which were already there), but even the minor additions reveal the inherent power. For example, JumpThreading is now capable of doing an inductive proof that a particular value is always positive and removing a half range check. I'm currently only using the new intersect function in one place. If folks are happy with the direction of the work, I plan on making a series of small changes without review to replace mergeIn with intersect at all the appropriate places. Differential Revision: http://reviews.llvm.org/D14476 llvm-svn: 259461
* [safestack] Make sure the unsafe stack pointer is popped in all casesAnna Zaks2016-02-023-4/+8
| | | | | | | | | | The unsafe stack pointer is only popped in moveStaticAllocasToUnsafeStack so it won't happen if there are no static allocas. Fixes https://llvm.org/bugs/show_bug.cgi?id=26122 Differential Revision: http://reviews.llvm.org/D16339 llvm-svn: 259447
* [LVI] Missing test case from 259432Philip Reames2016-02-011-0/+25
| | | | llvm-svn: 259437
OpenPOWER on IntegriCloud