summaryrefslogtreecommitdiffstats
path: root/llvm/test/Transforms
Commit message (Collapse)AuthorAgeFilesLines
* [InstCombine] Don't blow up in foldICmpWithCastAndCast on vector icmp ↵Daniel Neilson2018-03-051-0/+12
| | | | | | | | | | | | | | | | | | | | | | | instructions. Summary: Presently, InstCombiner::foldICmpWithCastAndCast() implicitly assumes that it is only invoked with icmp instructions of integer type. If that assumption is broken, and it is called with an icmp of vector type, then it fails (asserts/crashes). This patch addresses the deficiency. It allows it to simplify icmp (ptrtoint x), (ptrtoint/c) of vector type into a compare of the inputs, much as is done when the type is integer. Reviewers: apilipenko, fedor.sergeev, mkazantsev, anna Reviewed By: anna Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D44063 llvm-svn: 326730
* [InstCombine] Add constant vector support to getMinimumFPType for visitFPTrunc.Craig Topper2018-03-051-8/+19
| | | | | | | | This patch teaches getMinimumFPType to support shrinking a vector of ConstantFPs. This should improve our ability to combine vector fptrunc with fp binops. Differential Revision: https://reviews.llvm.org/D43774 llvm-svn: 326729
* [IPSCCP] Add getCompare which returns either true, false, undef or null.Florian Hahn2018-03-051-0/+26
| | | | | | | | | | | | | | | getCompare returns true, false or undef constants if the comparison can be evaluated, or nullptr if it cannot. This is in line with what ConstantExpr::getCompare returns. It also allows us to use ConstantExpr::getCompare for comparing constants. Reviewers: davide, mssimpso, dberlin, anna Reviewed By: davide Differential Revision: https://reviews.llvm.org/D43761 llvm-svn: 326720
* [MergeICmp] We can discard initial blocks that do other workXin Tong2018-03-051-0/+64
| | | | | | | | | | | | | | | | Summary: We can discard initial blocks that do other work We do not need to limit ourselves to just the first block in the chain. Reviewers: courbet, davide Reviewed By: courbet Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D44029 llvm-svn: 326698
* [CallSiteSplitting] properly split musttail callsFedor Indutny2018-03-031-0/+75
| | | | | | | | | | | | | | | | | | | | Summary: `musttail` calls can't be naively splitted. The split blocks must include not only the call instruction itself, but also (optional) `bitcast` and `return` instructions that follow it. Clone `bitcast` and `ret`, place them into the split blocks, and remove the tail block when done. Reviewers: junbuml, mcrosier, davidxl, davide, fhahn Reviewed By: fhahn Subscribers: JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D43729 llvm-svn: 326666
* [InstCombine] add test for vectors with undef elts; NFCSanjay Patel2018-03-031-1/+14
| | | | llvm-svn: 326661
* [InstCombine] (~X) - (~Y) --> Y - XSanjay Patel2018-03-031-4/+2
| | | | llvm-svn: 326660
* [InstCombine] add tests for notnotsub; NFCSanjay Patel2018-03-031-0/+36
| | | | | | | As shown in D44043, we may need this fold in the backend, but it's also missing in the IR optimizer. llvm-svn: 326659
* [ThinLTO] Revert r325320: Import global variablesChandler Carruth2018-03-022-12/+3
| | | | | | | | | | | | | | This caused some links to fail with ThinLTO due to missing symbols as well as causing some binaries to have failures at runtime. We're working with the author to get a test case, but want to get the tree green again. Further, it appears to introduce a data race. While the test usage of threads was disabled in r325361 & r325362, that isn't an acceptable fix. I've reverted both of these as well. This code needs to be thread safe. Test cases for this are already on the original commit thread. llvm-svn: 326638
* [InstCombine] partly fix FMF for fmul+log2 foldSanjay Patel2018-03-021-6/+6
| | | | | | | | | | The code was checking that all of the instructions in the sequence are 'fast', but that's not necessary. The final multiply is all that we need to check (tests adjusted). The fmul doesn't need to be fully 'fast' either, but that can be another patch. llvm-svn: 326608
* [InstCombine] add tests for rL169025; NFCSanjay Patel2018-03-021-0/+32
| | | | | | | | This narrow fold was added with no motivation or test cases a bit over 5 years ago. Removing a constant operand is a good canonicalization? We should handle Y*2.0 too then? llvm-svn: 326606
* [InstCombine] Allow fptrunc (fpext X)) to be reduced to a single fpext/ftruncCraig Topper2018-03-022-18/+9
| | | | | | | | | | If we are only truncating bits from the extend we should be able to just use a smaller extend. If we are truncating more than the extend we should be able to just use a fptrunc since the presense of the fpextend shouldn't affect rounding. Differential Revision: https://reviews.llvm.org/D43970 llvm-svn: 326595
* LoopUnroll: respect pragma unroll when AllowRemainder is disabledYaxun Liu2018-03-022-26/+133
| | | | | | | | | | | | | Currently when AllowRemainder is disabled, pragma unroll count is not respected even though there is no remainder. This bug causes a loop fully unrolled in many cases even though the user specifies a unroll count. Especially it affects OpenCL/CUDA since in many cases a loop contains convergent instructions and currently AllowRemainder is disabled for such loops. Differential Revision: https://reviews.llvm.org/D43826 llvm-svn: 326585
* [MergeICmps] Revert accidentally submitted failing test case.Clement Courbet2018-03-021-160/+0
| | | | | | Reverts r326574. llvm-svn: 326582
* [MergeIcmps] Add the test case from PR36557.Clement Courbet2018-03-021-0/+160
| | | | | | | | | | Summary: See PR36557. Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D44009 llvm-svn: 326574
* [InstCombine] Add more test case to fpextend.ll.Craig Topper2018-03-021-0/+186
| | | | | | This includes the test cases from D43970 and additional tests for combining (fptrunc (binop (fpext), (fpext))) where the pre-extended types don't match the trunc and therefore can't be completely removed. llvm-svn: 326528
* [ArgumentPromotion] don't break musttail invariant PR36543Fedor Indutny2018-03-021-0/+45
| | | | | | | | | | | | | | | | Summary: Do not break musttail invariant by promoting arguments of musttail callee or caller. Reviewers: sanjoy, dberlin, hfinkel, george.burgess.iv, fhahn, rnk Reviewed By: rnk Subscribers: rnk, llvm-commits Differential Revision: https://reviews.llvm.org/D43926 llvm-svn: 326521
* [InstCombine] Simplify test cases by removing loads/stores that aren't ↵Craig Topper2018-03-021-72/+40
| | | | | | | | required for what is being tested. The loads and stores were getting the data and storing the results. There's no reason we can't just use function arguments and return. llvm-svn: 326515
* [InstCombine] allow fmul fold with less than 'fast'Sanjay Patel2018-03-022-13/+14
| | | | | | | | | | | | | | | | | | This is a retry of r326502 with updates to the reassociate test file that I missed the first time. @test15_reassoc in the supposed -reassociate test file (except that it tests 2 other passes too...) shows that there's no clear responsiblity for reassociation transforms. Instcombine now gets that case, but only because the constant values are identical. Otherwise, it would still miss that pattern. Reassociate doesn't get that case because it hasn't been updated to use less than 'fast' FMF. llvm-svn: 326513
* [Reassociate] regenerate checks; NFCSanjay Patel2018-03-011-61/+62
| | | | llvm-svn: 326511
* revert r326502: [InstCombine] allow fmul fold with less than 'fast'Sanjay Patel2018-03-011-13/+11
| | | | | | | | I forgot that I added tests for 'reassoc' to -reassociate, but suprisingly that file calls -instcombine too, so it is affected. I'll update that file and try again. llvm-svn: 326510
* [InstCombine] allow fmul fold with less than 'fast'Sanjay Patel2018-03-011-11/+13
| | | | llvm-svn: 326502
* [InstCombine] Auto-generate complete checks. NFCCraig Topper2018-03-011-141/+246
| | | | llvm-svn: 326474
* [InstCombine] remove stale comments for tests; NFCSanjay Patel2018-03-011-3/+0
| | | | llvm-svn: 326448
* [InstCombine] move/add tests for fmul reassociation; NFCSanjay Patel2018-03-012-12/+72
| | | | | | | This transform may be out-of-scope for instcombine, but this is only documenting the current behavior. llvm-svn: 326442
* [InstCombine] auto-generate full checks; NFCSanjay Patel2018-03-011-51/+49
| | | | llvm-svn: 326440
* [SCEV] Smart range calculation for SCEVUnknown PhisMax Kazantsev2018-03-012-3/+109
| | | | | | | | | | The range of SCEVUnknown Phi which merges values `X1, X2, ..., XN` can be evaluated as `U(Range(X1), Range(X2), ..., Range(XN))`. Reviewed By: sanjoy Differential Revision: https://reviews.llvm.org/D43810 llvm-svn: 326418
* [IPSCCP] do not break musttail invariant (PR36485)Reid Kleckner2018-03-011-0/+58
| | | | | | | | | | | | | | | | | Do not replace results of `musttail` calls with a constant if the call itself can't be removed. Do not zap returns of `musttail` callees, if the call site can't be removed and replaced with a constant. Do not zap returns of `musttail`-calling blocks, this breaks invariant too. Patch by Fedor Indutny Differential Revision: https://reviews.llvm.org/D43695 llvm-svn: 326404
* [DAE] don't remove args of musttail target/callerReid Kleckner2018-03-011-0/+16
| | | | | | | | | | | | | `musttail` requires identical signatures of caller and callee. Removing arguments breaks `musttail` semantics. PR36441 Patch by Fedor Indutny Differential Revision: https://reviews.llvm.org/D43708 llvm-svn: 326394
* [InstCombine] simplify code for X * -1.0 --> -X; NFCSanjay Patel2018-02-281-2/+2
| | | | | | I've added random FMF to one of the tests to show those are propagated. llvm-svn: 326377
* [GlobalOpt] don't change CC of musttail calle(e|r)Jonas Devlieghere2018-02-281-0/+34
| | | | | | | | | | | | | | | When the function has musttail call - its cc is fixed to be equal to the cc of the musttail callee. In such case (and in the case of the musttail callee), GlobalOpt should not change the cc to fastcc as it will break the invariant. This fixes PR36546 Patch by: Fedor Indutny (indutny) Differential revision: https://reviews.llvm.org/D43859 llvm-svn: 326376
* [InstCombine] auto-generate complete checks; NFCSanjay Patel2018-02-281-26/+36
| | | | llvm-svn: 326331
* [MergeICmp] Fix a bug in MergeICmp that can lead to a block being processed ↵Xin Tong2018-02-281-0/+57
| | | | | | | | | | | | | | | | | | | | | more than once. Summary: Fix a bug in MergeICmp that can lead to a BCECmp block being processed more than once and eventually lead to a broken LLVM module. The problem is that if the non-constant value is not produced by the last block, the producer will be processed once when the its parent block is processed and second time when the last block is processed. We end up having 2 same BCECmpBlock in the merge queue. And eventually lead to a broken LLVM module. Reviewers: courbet, davide Reviewed By: courbet Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D43825 llvm-svn: 326318
* [SLP] Added new tests and updated existing for jumbled load, NFC.Mohammad Shahid2018-02-284-6/+468
| | | | llvm-svn: 326303
* [InstSimplify] add tests for FP with undef operand; NFCSanjay Patel2018-02-272-18/+89
| | | | | | Are any of these correct? llvm-svn: 326241
* [ValueTracking] Teach cannotBeOrderedLessThanZeroImpl to look through ↵Craig Topper2018-02-271-0/+14
| | | | | | | | | | ExtractElement. This is similar to what's done in computeKnownBits and computeSignBits. Don't do anything fancy just collect information valid for any element. Differential Revision: https://reviews.llvm.org/D43789 llvm-svn: 326237
* [ARM] add loop vectorizer test based on 482.sphinx3 from SPEC2006; NFCSanjay Patel2018-02-271-0/+165
| | | | | | | | This is a slight reduction of one of the benchmarks that suffered with D43079. Cost model changes should not cause this test to remain scalarized. llvm-svn: 326221
* [AArch64] add SLP test based on TSVC; NFCSanjay Patel2018-02-271-0/+127
| | | | | | | | This is a slight reduction of one of the benchmarks that suffered with D43079. Cost model changes should not cause this test to remain scalarized. llvm-svn: 326217
* [NewGVN] Update phi-of-ops def block when updating existing ValuePHI.Florian Hahn2018-02-271-0/+56
| | | | | | | | | | | | | | | | | | | | | | | | | In case we update a ValuePHI node created earlier, we could update it based on a different OpPHI which could be in a different block. We need to update the TempToBlock mapping reflecting the new block, otherwise we would end up placing the new phi node in a wrong block. This problem is exposed by the test case in https://bugs.llvm.org/show_bug.cgi?id=36504. This patch fixes a slightly simpler problem than in the bug report. In the bug's re-producer, the additional problem is that we are re-using a ValuePHI node with to few incoming values for the new OpPHI. If this patch makes sense, I will follow it up with a patch that creates a new PHI node if the existing PHI node has a different number of incoming values. Reviewers: davide, dberlin Reviewed By: dberlin Differential Revision: https://reviews.llvm.org/D43770 llvm-svn: 326181
* Make test agnostic to cost modelAdam Nemet2018-02-271-1/+1
| | | | | | This was causing bot failures on greendragon llvm-svn: 326169
* Fix r326154 buildbots test failEvgeny Stupachenko2018-02-272-3/+2
| | | | | | | | | | Summary: Add specific mtriples to tests added in r326154. From: Evgeny Stupachenko <evstupac@gmail.com> <evgeny.v.stupachenko@intel.com> llvm-svn: 326158
* Fix PR36032, PR35432Evgeny Stupachenko2018-02-272-0/+367
| | | | | | | | | | | | | | | Summary: The change fix an assert fail at ScalarEvolutionExpander.cpp: assert(ExitCount != SE.getCouldNotCompute() && "Invalid loop count"); Reviewers: sbaranga Differential Revision: http://reviews.llvm.org/D42604 From: Evgeny Stupachenko <evstupac@gmail.com> <evgeny.v.stupachenko@intel.com> llvm-svn: 326154
* [InstCombine, InstSimplify] add tests with undef elements in constant FP ↵Sanjay Patel2018-02-262-0/+62
| | | | | | vectors; NFC llvm-svn: 326148
* [ValueTracking] Teach cannotBeOrderedLessThanZeroImpl to handle vector ↵Craig Topper2018-02-261-4/+2
| | | | | | | | | | | | | | | | constants. Summary: This allows vector fabs to be removed in more cases. Reviewers: spatel, arsenm, RKSimon Reviewed By: spatel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D43739 llvm-svn: 326138
* [X86][SSE] Reduce FADD/FSUB/FMUL costs on later targets (PR36280)Simon Pilgrim2018-02-265-146/+109
| | | | | | | | | | Agner's tables indicate that for SSE42+ targets (Core2 and later) we can reduce the FADD/FSUB/FMUL costs down to 1, which should fix the Himeno benchmark. Note: the AVX512 FDIV costs look rather dodgy, but this isn't part of this patch. Differential Revision: https://reviews.llvm.org/D43733 llvm-svn: 326133
* [SLP] Added new test + fixed some checks, NFC.Alexey Bataev2018-02-262-13/+175
| | | | llvm-svn: 326117
* [InstCombine] Add test cases with vector constants to fpextend.llCraig Topper2018-02-261-0/+41
| | | | llvm-svn: 326115
* [InstCombine] Switch to using FileCheck instead of grep. Auto-generate ↵Craig Topper2018-02-261-30/+61
| | | | | | checks. NFC llvm-svn: 326114
* [InstCombine] allow fdiv folds with less than fully 'fast' opsSanjay Patel2018-02-261-8/+8
| | | | | | | | | | | | | | | | | | Note: gcc appears to allow this fold with -freciprocal-math alone, but clang/llvm require more than that with this patch. The wording in the definitions seems fuzzy enough that it could go either way, but we'll err on the conservative side of FMF interpretation. This patch also changes the newly created fmul to have FMF propagated by the last fdiv rather than intersecting the FMF of the fdivs. This matches the behavior of other folds near here. The new fmul is only used to produce an intermediate op for the final fdiv result, so it shouldn't be any stricter than that result. The previous behavior could result in dropping FMF via other folds in instcombine or CSE. Differential Revision: https://reviews.llvm.org/D43398 llvm-svn: 326098
* [LV] Move isLegalMasked* functions from Legality to CostModelRenato Golin2018-02-262-2/+3
| | | | | | | | | | | | | | | | | | | | | | | All SIMD architectures can emulate masked load/store/gather/scatter through element-wise condition check, scalar load/store, and insert/extract. Therefore, bailing out of vectorization as legality failure, when they return false, is incorrect. We should proceed to cost model and determine profitability. This patch is to address the vectorizer's architectural limitation described above. As such, I tried to keep the cost model and vectorize/don't-vectorize behavior nearly unchanged. Cost model tuning should be done separately. Please see http://lists.llvm.org/pipermail/llvm-dev/2018-January/120164.html for RFC and the discussions. Closes D43208. Patch by: Hideki Saito <hideki.saito@intel.com> llvm-svn: 326079
OpenPOWER on IntegriCloud