summaryrefslogtreecommitdiffstats
path: root/llvm/test/Transforms
Commit message (Collapse)AuthorAgeFilesLines
* [SLPVectorizer][X86] Regenerated SEXT/ZEXT cast vectorization testsSimon Pilgrim2016-05-061-8/+94
| | | | | | Added 256-bit vector test as well llvm-svn: 268811
* Reapply 267210 with fix for PR27490Philip Reames2016-05-061-0/+61
| | | | | | | | | | | Original Commit Message Extend load/store type canonicalization to handle unordered operations Extend the type canonicalization logic to work for unordered atomic loads and stores. Note that while this change itself is fairly simple and low risk, there's a reasonable chance this will expose problems in the backends by suddenly generating IR they wouldn't have seen before. Anything of this nature will be an existing bug in the backend (you could write an atomic float load), but this will definitely change the frequency with which such cases are encountered. If you see problems, feel free to revert this change, but please make sure you collect a test case. Note that the concern about lowering is now much less likely. PR27490 proved that we already *were* mucking with the types of ordered atomics and volatiles. As a result, this change doesn't introduce as much new behavior as originally thought. llvm-svn: 268809
* [GVN] PRE of unordered loadsPhilip Reames2016-05-061-0/+109
| | | | | | Again, fairly simple. Only change is ensuring that we actually copy the property of the load correctly. The aliasing legality constraints were already handled by the FRE patches. There's nothing special about unorder atomics from the perspective of the PRE algorithm itself. llvm-svn: 268804
* [SLPVectorizer][X86] Added BSWAP/BITREVERSE vectorization testsSimon Pilgrim2016-05-062-0/+934
| | | | llvm-svn: 268803
* [SLPVectorizer][X86] Added CTPOP/CTLZ/CTTZ vectorization testsSimon Pilgrim2016-05-063-0/+2847
| | | | llvm-svn: 268800
* [GVN] Handle unordered atomics in cross block FREPhilip Reames2016-05-061-0/+55
| | | | | | You'll note there are essentially no code changes here. Cross block FRE heavily reuses code from the block local FRE. All of the tricky parts were done as part of the previous patch and the refactoring that removed the original code duplication. llvm-svn: 268775
* [GVN] Do local FRE for unordered atomic loadsPhilip Reames2016-05-061-0/+230
| | | | | | | | | | This patch is the first in a small series teaching GVN to optimize unordered loads aggressively. This change just handles block local FRE because that's the simplest thing which lets me test MDA, and the AvailableValue pieces. Somewhat suprisingly, MDA appears fine and only a couple of small changes are needed in GVN. Once this is in, I'll tackle non-local FRE and PRE. The former looks like a natural extension of this, the later will require a couple of minor changes. Differential Revision: http://reviews.llvm.org/D19440 llvm-svn: 268770
* [SimplifyCFG] propagate branch metadata when creating select (retry r268550 ↵Sanjay Patel2016-05-061-8/+39
| | | | | | | | | | | | | | | | / r268751 with possible fix) Retrying r268550/r268751 which were reverted at r268577/r268765 due a memory sanitizer failure. I have not been able to reproduce that failure, but I've taken another guess at fixing the problem in this version of the patch and will watch for another failure. Original commit message: Unlike earlier similar fixes, we need to recalculate the branch weights in this case. Differential Revision: http://reviews.llvm.org/D19674 llvm-svn: 268767
* revert r268751 - caused same failures on msan botSanjay Patel2016-05-061-39/+8
| | | | llvm-svn: 268765
* [SimplifyCFG] propagate branch metadata when creating select (retry r268550 ↵Sanjay Patel2016-05-061-8/+39
| | | | | | | | | | | | | | | | with possible fix) Retrying r268550 which was reverted at r268577 due a memory sanitizer failure. I have not been able to reproduce that failure, but I've taken a guess at fixing the problem in this version of the patch and will watch for another failure. Original commit message: Unlike earlier similar fixes, we need to recalculate the branch weights in this case. Differential Revision: http://reviews.llvm.org/D19674 llvm-svn: 268751
* [SimplifyCFG] Prefer a simplification based on a dominating condition.Chad Rosier2016-05-061-0/+48
| | | | | | | Rather than merge two branches with a common destination. Differential Revision: http://reviews.llvm.org/D19743 llvm-svn: 268735
* [PM] port IR based PGO prof-gen pass to new pass managerXinliang David Li2016-05-0611-0/+14
| | | | llvm-svn: 268710
* [PM] Port Interprocedural SCCP to the new pass manager.Davide Italiano2016-05-051-0/+1
| | | | llvm-svn: 268684
* Revert http://reviews.llvm.org/D19926 as it breaks tests.Dehao Chen2016-05-052-6/+19
| | | | llvm-svn: 268681
* Simplify CFG before assigning discriminator.Dehao Chen2016-05-052-19/+6
| | | | | | | | | | | | Summary: We need to clean up CFG before assigning discriminator to minimize the impact of optimization on debug info. Reviewers: davidxl, dblaikie, dnovillo Subscribers: dnovillo, danielcdh, llvm-commits Differential Revision: http://reviews.llvm.org/D19926 llvm-svn: 268675
* [ValueTracking] Improve isImpliedCondition for matching LHS and Imm RHSs.Chad Rosier2016-05-052-1/+142
| | | | llvm-svn: 268636
* [LV] Identify more induction PHIs by coercing expressions to AddRecExprsSilviu Baranga2016-05-051-0/+75
| | | | | | | | | | | | | | | | | | Summary: Some PHIs can have expressions that are not AddRecExprs due to the presence of sext/zext instructions. In order to prevent the Loop Vectorizer from bailing out when encountering these PHIs, we now coerce the SCEV expressions to AddRecExprs using SCEV predicates (when possible). We only do this when the alternative would be to not vectorize. Reviewers: mzolotukhin, anemet Subscribers: mssimpso, sanjoy, mzolotukhin, llvm-commits Differential Revision: http://reviews.llvm.org/D17153 llvm-svn: 268633
* [PM] Port EliminateAvailableExternally pass to the new pass manager.Davide Italiano2016-05-051-1/+1
| | | | llvm-svn: 268599
* [PM] Port ConstantMerge to the new pass manager.Davide Italiano2016-05-051-1/+1
| | | | llvm-svn: 268582
* [LoopDataPrefetch] Add optimization remarkAdam Nemet2016-05-051-0/+78
| | | | | | | With -Rpass=loop-data-prefetch, show the memory access that got prefetched. llvm-svn: 268578
* Revert "[SimplifyCFG] propagate branch metadata when creating select"Vitaly Buka2016-05-041-39/+8
| | | | | | | | | | | | MemorySanitizer: use-of-uninitialized-value 0x4910e47 in count /mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm/include/llvm/Support/MathExtras.h:159:12 0x4910e47 in countLeadingZeros<unsigned long> /mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm/include/llvm/Support/MathExtras.h:183 0x4910e47 in FitWeights /mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm/lib/Transforms/Utils/SimplifyCFG.cpp:855 0x4910e47 in SimplifyCondBranchToCondBranch /mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm/lib/Transforms/Utils/SimplifyCFG.cpp:2895 This reverts commit 609f4dd4bf3bc735c8c047a4d4b0a8e9e4d202e2. llvm-svn: 268577
* "Reapply r268521 "[InstCombine] Canonicalize icmp instructions based on ↵Balaram Makam2016-05-042-2/+122
| | | | | | | | | dominating conditions."" This reapplies commit r268521, that was reverted in r268530 due to a test failure in select-implied.ll Modified the test case to reflect the new change. llvm-svn: 268557
* [SimplifyCFG] propagate branch metadata when creating selectSanjay Patel2016-05-041-8/+39
| | | | | | | | | Unlike earlier similar fixes, we need to recalculate the branch weights in this case. Differential Revision: http://reviews.llvm.org/D19674 llvm-svn: 268550
* [ConstantFold] Don't try to strip fp -> int bitcasts to simplify icmpsHal Finkel2016-05-041-0/+52
| | | | | | | | | | | | | ConstantFold has logic to take icmp (bitcast x to y), null and strip the bitcast. This makes sense in general, but not if x has floating-point type. In this case, we'd need a fcmp, not an icmp, and the code will assert. We normally don't see this situation because we constant fold fp -> int bitcasts, however, we'll see it for bitcasts of ppc_fp128 -> i128. This is because that bitcast is Endian-dependent, and as a result, we don't simplify it in ConstantFold (we could, but no one has yet added the necessary logic). Regardless, ConstantFold should not depend on that canonicalization for correctness. llvm-svn: 268534
* Revert "[InstCombine] Canonicalize icmp instructions based on dominating ↵Balaram Makam2016-05-041-118/+0
| | | | | | | | conditions." This reverts commit 573a40f79b35cf3e71db331bb00f6a84f03b835d. llvm-svn: 268530
* Adding test cases showing the behavior of LoopUnrollPass according to ↵Marianne Mailhot-Sarrasin2016-05-041-0/+160
| | | | | | | | | | optnone and optsize attributes The unroll pass was disabled by clang in /Os. Those new test cases shows that the pass will behave correctly even if it is not fully disabled. This patch is related in some way to the clang commit (http://reviews.llvm.org/D19827), which re-enables the pass in /Os. Differential Revision: http://reviews.llvm.org/D19870 llvm-svn: 268524
* [InstCombine] Canonicalize icmp instructions based on dominating conditions.Balaram Makam2016-05-041-0/+118
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch canonicalizes conditions based on the constant range information of the dominating branch condition. For example: %cmp = icmp slt i64 %a, 0 br i1 %cmp, label %land.lhs.true, label %lor.rhs lor.rhs: %cmp2 = icmp sgt i64 %a, 0 Would now be canonicalized into: %cmp = icmp slt i64 %a, 0 br i1 %cmp, label %land.lhs.true, label %lor.rhs lor.rhs: %cmp2 = icmp ne i64 %a, 0 Reviewers: mcrosier, gberry, t.p.northover, llvm-commits, reames, hfinkel, sanjoy, majnemer Subscribers: MatzeB, majnemer, mcrosier Differential Revision: http://reviews.llvm.org/D18841 llvm-svn: 268521
* [SimplifyCFG] isSafeToSpeculateStore now ignores debug infoHans Wennborg2016-05-041-0/+68
| | | | | | | | | | | | | | | This patch fixes PR27615. @llvm.dbg.value instructions no longer count towards the maximum number of instructions to look back at in the instruction list when searching for a store instruction. This should make the output consistent between debug and non-debug build. Patch by Henric Karlsson <henric.karlsson@ericsson.com>! Differential Revision: http://reviews.llvm.org/D19912 llvm-svn: 268512
* [RS4GC] Use SetVector/MapVector instead of DenseSet/DenseMap to guarantee ↵Igor Laevsky2016-05-044-7/+7
| | | | | | | | | | | | | | | stable ordering Goal of this change is to guarantee stable ordering of the statepoint arguments and other newly inserted values such as gc.relocates. Previously we had explicit sorting in a couple of places. However for unnamed values ordering was partial and overall we didn't have any strong invariant regarding it. This change switches all data structures to use SetVector's and MapVector's which provide possibility for deterministic iteration over them. Explicit sorting is now redundant and was removed. Differential Revision: http://reviews.llvm.org/D19669 llvm-svn: 268502
* [ConstantFolding, ValueTracking] Fold constants involving bitcasts of ↵David Majnemer2016-05-041-0/+8
| | | | | | | | | | | | | | | | | ConstantVector We assumed that ConstantVectors would be rather uninteresting from the perspective of analysis. However, this is not the case due to a quirk of how LLVM handles vectors of i1. Vectors of i1 are not ConstantDataVectors like vectors of i8, i16, i32 or i64 because i1's SizeInBits differs from it's StoreSizeInBytes. This leads to it being categorized as a ConstantVector instead of a ConstantDataVector. Instead, treat ConstantVector more uniformly. This fixes PR27591. llvm-svn: 268479
* [GlobalDCE, Misc] Don't remove functions referenced by ifuncsDavid Majnemer2016-05-041-0/+13
| | | | | | | | | | | | We forgot to consider the target of ifuncs when considering if a function was alive or dead. N.B. Also update a few auxiliary tools like bugpoint and verify-uselistorder. This fixes PR27593. llvm-svn: 268468
* PM: Port LoopRotation to the new loop pass managerJustin Bogner2016-05-031-0/+2
| | | | llvm-svn: 268452
* PM: Port LoopSimplifyCFG to the new pass managerJustin Bogner2016-05-031-0/+1
| | | | llvm-svn: 268446
* [RS4GC] Add a test case around calling conventions; NFCSanjoy Das2016-05-031-0/+11
| | | | llvm-svn: 268436
* [IPO/GlobalDCE] Port to the new pass manager.Davide Italiano2016-05-031-1/+1
| | | | | | Differential Revision: http://reviews.llvm.org/D19782 llvm-svn: 268425
* [SROA] Function canConvertValue needs to check whether both NewTy and OldTy ↵Jack Liu2016-05-031-1/+18
| | | | | | | | | | | pointers are pointing to the same addr space. This can prevent SROA from creating a bitcast between pointers with different addr spaces. Differential Revision: http://reviews.llvm.org/D19697 llvm-svn: 268424
* Revert 268409 due to missing comment.Jack Liu2016-05-031-18/+1
| | | | llvm-svn: 268421
* (no commit message)Jack Liu2016-05-031-1/+18
| | | | llvm-svn: 268409
* [LICM] Kill SCEV loop dispositions if neededSanjoy Das2016-05-031-0/+31
| | | | | | | | SCEV caches whether SCEV expressions are loop invariant, variant or computable. LICM breaks this cache, almost by definition; so clear the SCEV disposition cache if LICM changed anything. llvm-svn: 268408
* Use all_of instead of a raw loop; NFCSanjoy Das2016-05-031-2/+56
| | | | | | | Added some tests despite being NFC, since it looks like nothing was exercising the "all incoming values to exit PHIs are same" logic. llvm-svn: 268407
* [LoopDeletion] Clear SCEV loop dispositionsSanjoy Das2016-05-031-0/+56
| | | | | | | | | | | `Loop::makeLoopInvariant` can hoist instructions out of loops, so loop dispositions for the loop it operated on may need to be cleared. We can be smarter here (especially around how `forgetLoopDispositions` is implemented), but let's be correct first. Fixes PR27570. llvm-svn: 268406
* Fold compares irrespective of whether allocation can be elidedAnna Thomas2016-05-031-9/+81
| | | | | | | | | | | | | | | | | | | Summary When a non-escaping pointer is compared to a global value, the comparison can be folded even if the corresponding malloc/allocation call cannot be elided. We need to make sure the global value is not null, since comparisons to null cannot be folded. In future, we should also handle cases when the the comparison instruction dominates the pointer escape. Reviewers: sanjoy Subscribers s.egerton, llvm-commits Differential Revision: http://reviews.llvm.org/D19549 llvm-svn: 268390
* Mark that SpeculativeExecution preserves Globals Alias Analysis.Kristof Beyls2016-05-031-0/+26
| | | | | | | | | | | | | | | | | | | | A few benchmarks with lots of accesses to global variables in the hot loops regressed a lot since r266399, which added the SpeculativeExecution pass to the default pipeline. The problem is that this pass doesn't mark Globals Alias Analysis as preserved. Globals Alias Analysis is computed in a module pass, whereas SpeculativeExecution is a function pass, and a lot of passes dependent on the Globals Alias Analysis to optimize these benchmarks are also function passes. As such, the Globals Alias Analysis information cannot be recomputed between SpeculativeExecution and the following function passes needing that information. SpeculativeExecution doesn't invalidate Globals Alias Analysis, so mark it as such to fix those performance regressions. Differential Revision: http://reviews.llvm.org/D19806 llvm-svn: 268370
* test commitJack Liu2016-05-031-1/+1
| | | | llvm-svn: 268358
* [LoopUnroll] Unroll loops which have exit blocks to EH padsDavid Majnemer2016-05-031-0/+40
| | | | | | | | | | | | | We were overly cautious in our analysis of loops which have invokes which unwind to EH pads. The loop unroll transform is safe because it only clones blocks in the loop body, it does not try to split critical edges involving EH pads. Instead, move the necessary safety check to LoopUnswitch. N.B. The safety check for loop unswitch is covered by an existing test which fails without it. llvm-svn: 268357
* ThinLTO: do not import function whose linkage prevents inlining.Mehdi Amini2016-05-032-0/+10
| | | | | | | | | | | There is not point in importing a "weak" or a "linkonce" function since we won't be able to inline it anyway. We already had a targeted check for WeakAny, this is using the same check on GlobalValue as the inline, i.e. isMayBeOverriddenLinkage() From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 268341
* Revert "ThinLTO: do not import function whose linkage prevents inlining."Mehdi Amini2016-05-022-10/+0
| | | | | | | This reverts commit r268315, the tests are not passing. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 268317
* ThinLTO: do not import function whose linkage prevents inlining.Mehdi Amini2016-05-022-0/+10
| | | | | | | | | | | There is not point in importing a "weak" or a "linkonce" function since we won't be able to inline it anyway. We already had a targeted check for WeakAny, this is using the same check on GlobalValue as the inline, i.e. isMayBeOverriddenLinkage() From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 268315
* Revert "[SimplifyCFG] Extend TryToSimplifyUncondBranchFromEmptyBlock for ↵Reid Kleckner2016-05-021-232/+0
| | | | | | | | | | | empty block including lifetime intrinsics" This reverts commit r268254. This change causes assertion failures while building Chromium. Reduced test case coming soon. llvm-svn: 268288
* [SimplifyCFG] Extend TryToSimplifyUncondBranchFromEmptyBlock for empty block ↵Hans Wennborg2016-05-021-0/+232
| | | | | | | | | | | | | | | | | | including lifetime intrinsics Make it possible that TryToSimplifyUncondBranchFromEmptyBlock merges empty basic block including lifetime intrinsics as well as phi nodes and unconditional branch into its successor or predecessor(s). If successor of empty block has single predecessor, all contents including lifetime intrinsics are sinked into the successor. Otherwise, they are hoisted into its predecessor(s) and then merged into the predecessor(s). Patch by Josh Yoon <josh.yoon@samsung.com>! Differential Revision: http://reviews.llvm.org/D19257 llvm-svn: 268254
OpenPOWER on IntegriCloud