summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/InstCombine
Commit message (Collapse)AuthorAgeFilesLines
...
* Revert "[InstCombine] improve readability; NFC"Sanjay Patel2019-12-061-6/+10
| | | | | This reverts commit 7250ef3613cc6b81145b9543bafb86d7f9466cde. At least 1 of these supposedly NFC commits wasn't - sanitizer bot is angry.
* Revert "[InstCombine] reduce indentation; NFC"Sanjay Patel2019-12-061-25/+28
| | | | | This reverts commit 8bf8ef7116bd0daec570b35480ca969b74e66c6e. At least 1 of these supposedly NFC commits wasn't - sanitizer bot is angry.
* [InstCombine] reduce indentation; NFCSanjay Patel2019-12-061-28/+25
|
* [InstCombine] improve readability; NFCSanjay Patel2019-12-061-10/+6
| | | | CreateIntCast returns the input if its type matches, so need to duplicate that check.
* [InstCombine] reduce code duplication; NFCSanjay Patel2019-12-061-38/+40
|
* [InstCombine] improve readability; NFCSanjay Patel2019-12-061-33/+33
|
* Revert "[InstCombine] keep assumption before sinking calls"Bob Haarman2019-12-051-21/+2
| | | | | | | | | | | | | | | | | | | | | Summary: This reverts commit c3b06d0c393e533eab712922911d14e5a079fa5d. Reason for revert: Caused miscompiles when inserting assume for undef. Also adds a test to prevent similar breakage in future. Fixes PR44154. Reviewers: rnk, jdoerfert, efriedma, xbolva00 Reviewed By: rnk Subscribers: thakis, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70933
* [InstCombine] Invert `add A, sext(B) --> sub A, zext(B)` canonicalization ↵Roman Lebedev2019-12-051-6/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (to `sub A, zext B -> add A, sext B`) Summary: D68408 proposes to greatly improve our negation sinking abilities. But in current canonicalization, we produce `sub A, zext(B)`, which we will consider non-canonical and try to sink that negation, undoing the existing canonicalization. So unless we explicitly stop producing previous canonicalization, we will have two conflicting folds, and will end up endlessly looping. This inverts canonicalization, and adds back the obvious fold that we'd miss: * `sub [nsw] Op0, sext/zext (bool Y) -> add [nsw] Op0, zext/sext (bool Y)` https://rise4fun.com/Alive/xx4 * `sext(bool) + C -> bool ? C - 1 : C` https://rise4fun.com/Alive/fBl It is obvious that `@ossfuzz_9880()` / `@lshr_out_of_range()`/`@ashr_out_of_range()` (oss-fuzz 4871) are no longer folded as much, though those aren't really worrying. Reviewers: spatel, efriedma, t.p.northover, hfinkel Reviewed By: spatel Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71064
* [InstCombine] narrow select with FP castsSanjay Patel2019-12-051-0/+18
| | | | Select doesn't change values, so truncate of extended operand cancels out.
* [InstCombine] add FMF guard to builder in fptrunc transform; NFCSanjay Patel2019-12-051-0/+5
| | | | | | | | This makes no difference currently because we don't apply FMF to FP casts, but that may change. This could also be a place to add a fold for select with fptrunc, so it will make that patch easier/smaller.
* [InstCombine] Extend `0 - (X sdiv C) -> (X sdiv -C)` fold to non-splat vectorsRoman Lebedev2019-12-051-8/+10
| | | | Split off from https://reviews.llvm.org/D68408
* [APFloat] Prevent construction of APFloat with Semantics and FP valueEhud Katz2019-12-041-1/+1
| | | | | | | | | | | | | | | | | Constructor invocations such as `APFloat(APFloat::IEEEdouble(), 0.0)` may seem like they accept a FP (floating point) value, but the overload they reach is actually the `integerPart` one, not a `float` or `double` overload (which only exists when `fltSemantics` isn't passed). This may lead to possible loss of data, by the conversion from `float` or `double` to `integerPart`. To prevent future mistakes, a new constructor overload, which accepts any FP value and marked with `delete`, to prevent its usage. Fixes PR34095. Differential Revision: https://reviews.llvm.org/D70425
* [InstCombine] Revert aafde063aaf09285c701c80cd4b543c2beb523e8 and ↵Craig Topper2019-12-032-10/+2
| | | | | | | | | | | | | | | | 6749dc3446671df05235d0a218c426a314ac33cd related to bitcast handling of x86_mmx This reverts these two commits [InstCombine] Turn (extractelement <1 x i64/double> (bitcast (x86_mmx))) into a single bitcast from x86_mmx to i64/double. [InstCombine] Don't transform bitcasts between x86_mmx and v1i64 into insertelement/extractelement We're seeing at least one internal test failure related to a bitcast that was previously before an inline assembly block containing emms being placed after it. This leads to the mmx state ending up not empty after the emms. IR has no way to make any specific guarantees about this. Reverting these patches to get back to previous behavior which at least worked for this test.
* [InstCombine] fix undef propagation for vector urem transform (PR44186)Sanjay Patel2019-12-021-2/+4
| | | | | | | | | As described here: https://bugs.llvm.org/show_bug.cgi?id=44186 The match() code safely allows undef values, but we can't safely propagate a vector constant that contains an undef to the new compare instruction.
* [ARM,MVE] Add an InstCombine rule permitting VPNOT.Simon Tatham2019-12-021-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | Summary: If a user writing C code using the ACLE MVE intrinsics generates a predicate and then complements it, then the resulting IR will use the `pred_v2i` IR intrinsic to turn some `<n x i1>` vector into a 16-bit integer; complement that integer; and convert back. This will generate machine code that moves the predicate out of the `P0` register, complements it in an integer GPR, and moves it back in again. This InstCombine rule replaces `i2v(~v2i(x))` with a direct complement of the original predicate vector, which we can already instruction- select as the VPNOT instruction which complements P0 in place. Reviewers: ostannard, MarkMurrayARM, dmgreen Reviewed By: dmgreen Subscribers: kristof.beyls, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70484
* [InstCombine] Revert rL341831: relax one-use check in foldICmpAddConstant() ↵Roman Lebedev2019-12-021-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (PR44100) rL341831 moved one-use check higher up, restricting a few folds that produced a single instruction from two instructions to the case where the inner instruction would go away. Original commit message: > InstCombine: move hasOneUse check to the top of foldICmpAddConstant > > There were two combines not covered by the check before now, > neither of which actually differed from normal in the benefit analysis. > > The most recent seems to be because it was just added at the top of the > function (naturally). The older is from way back in 2008 (r46687) > when we just didn't put those checks in so routinely, and has been > diligently maintained since. From the commit message alone, there doesn't seem to be a deeper motivation, deeper problem that was trying to solve, other than 'fixing the wrong one-use check'. As i have briefly discusses in IRC with Tim, the original motivation can no longer be recovered, too much time has passed. However i believe that the original fold was doing the right thing, we should be performing such a transformation even if the inner `add` will not go away - that will still unchain the comparison from `add`, it will no longer need to wait for `add` to compute. Doing so doesn't seem to break any particular idioms, as least as far as i can see. References https://bugs.llvm.org/show_bug.cgi?id=44100
* [InstCombine] fold copysign with constant sign argument to (fneg+)fabsSanjay Patel2019-12-021-0/+15
| | | | | | | | | | | | | | | If the sign of the sign argument is known (this could be extended to use ValueTracking), then we can use fneg+fabs to clear/set the sign bit of the magnitude argument. http://llvm.org/docs/LangRef.html#llvm-copysign-intrinsic This transform is already done in DAGCombiner, but we can do it sooner in IR as suggested in PR44153: https://bugs.llvm.org/show_bug.cgi?id=44153 We have effectively no analysis for copysign in IR, so we are taking the unusual step of increasing the number of IR instructions for the negative constant case. Differential Revision: https://reviews.llvm.org/D70792
* [InstCombine] Fix big-endian miscompile of (bitcast (zext/trunc (bitcast)))Bjorn Pettersson2019-12-021-22/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: optimizeVectorResize is rewriting patterns like: %1 = bitcast vector %src to integer %2 = trunc/zext %1 %dst = bitcast %2 to vector Since bitcasting between integer an vector types gives different integer values depending on endianness, we need to take endianness into account. As it happens the old implementation only produced the correct result for little endian targets. Fixes: https://bugs.llvm.org/show_bug.cgi?id=44178 Reviewers: spatel, lattner, lebedev.ri Reviewed By: spatel, lebedev.ri Subscribers: lebedev.ri, hiraditya, uabelho, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70844
* [InstCombine] Expand usub_sat patterns to handle constantsDavid Green2019-11-301-3/+11
| | | | | | | | The constants come through as add %x, -C, not a sub as would be expected. They need some extra matchers to canonicalise them towards usub_sat. Differential Revision: https://reviews.llvm.org/D69514
* [InstCombine] Adjust usub_sat fold one use checksDavid Green2019-11-301-3/+3
| | | | | | This adjusts the one use checks in the the usub_sat fold code to not increase instruction count, but otherwise do the fold. Reviewed as a part of D69514.
* [InstCombine] remove shuffle mask canonicalization that creates undef elementsSanjay Patel2019-11-251-10/+10
| | | | | | This is NFC-intended because SimplifyDemandedVectorElts() does the same transform later. As discussed in D70641, we may want to change that behavior, so we need to isolate where it happens.
* [InstCombine] prevent infinite loop from conflicting shuffle mask transformsSanjay Patel2019-11-251-2/+4
| | | | | | | | | The pattern in question is currently not possible because we aggressively (wrongly) transform mask elements to undef values if they choose from an undef operand. That, however, would change if we tighten our semantics for shuffles as discussed in D70641. Adding this check gives us the flexibility to make that change with minimal overhead for current definitions.
* [InstCombine] simplify code for shuffle mask canonicalization; NFCSanjay Patel2019-11-251-6/+4
| | | | We never use the local 'Mask' before returning, so that was dead code.
* [InstCombine] remove dead code from shuffle mask canonicalization; NFCSanjay Patel2019-11-251-2/+2
|
* [InstCombine] simplify loop for shuffle mask canonicalization; NFCSanjay Patel2019-11-251-4/+4
|
* [InstCombine] remove identity shuffle simplification for mask with undefsSanjay Patel2019-11-242-24/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | And simultaneously enhance SimplifyDemandedVectorElts() to rcognize that pattern. That preserves some of the old optimizations in IR. Given a shuffle that includes undef elements in an otherwise identity mask like: define <4 x float> @shuffle(<4 x float> %arg) { %shuf = shufflevector <4 x float> %arg, <4 x float> undef, <4 x i32> <i32 undef, i32 1, i32 2, i32 3> ret <4 x float> %shuf } We were simplifying that to the input operand. But as discussed in PR43958: https://bugs.llvm.org/show_bug.cgi?id=43958 ...that means that per-vector-element poison that would be stopped by the shuffle can now leak to the result. Also note that we still have (and there are tests for) the same transform with no undef elements in the mask (a fully-defined identity mask). I don't think there's any controversy about that case - it's a valid transform under any interpretation of shufflevector/undef/poison. Looking at a few of the diffs into codegen, I don't see any difference in final asm. So depending on your perspective, that's good (no real loss of optimization power) or bad (poison exists in the DAG, so we only partially fixed the bug). Differential Revision: https://reviews.llvm.org/D70246
* [InstCombine] Fix call guard difference with dbgDavide Italiano2019-11-221-4/+4
| | | | | | Patch by Chris Ye! Differential Revision: https://reviews.llvm.org/D68004
* [cmake] Explicitly mark libraries defined in lib/ as "Component Libraries"Tom Stellard2019-11-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Most libraries are defined in the lib/ directory but there are also a few libraries defined in tools/ e.g. libLLVM, libLTO. I'm defining "Component Libraries" as libraries defined in lib/ that may be included in libLLVM.so. Explicitly marking the libraries in lib/ as component libraries allows us to remove some fragile checks that attempt to differentiate between lib/ libraries and tools/ libraires: 1. In tools/llvm-shlib, because llvm_map_components_to_libnames(LIB_NAMES "all") returned a list of all libraries defined in the whole project, there was custom code needed to filter out libraries defined in tools/, none of which should be included in libLLVM.so. This code assumed that any library defined as static was from lib/ and everything else should be excluded. With this change, llvm_map_components_to_libnames(LIB_NAMES, "all") only returns libraries that have been added to the LLVM_COMPONENT_LIBS global cmake property, so this custom filtering logic can be removed. Doing this also fixes the build with BUILD_SHARED_LIBS=ON and LLVM_BUILD_LLVM_DYLIB=ON. 2. There was some code in llvm_add_library that assumed that libraries defined in lib/ would not have LLVM_LINK_COMPONENTS or ARG_LINK_COMPONENTS set. This is only true because libraries defined lib lib/ use LLVMBuild.txt and don't set these values. This code has been fixed now to check if the library has been explicitly marked as a component library, which should now make it easier to remove LLVMBuild at some point in the future. I have tested this patch on Windows, MacOS and Linux with release builds and the following combinations of CMake options: - "" (No options) - -DLLVM_BUILD_LLVM_DYLIB=ON - -DLLVM_LINK_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_BUILD_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_LINK_LLVM_DYLIB=ON Reviewers: beanz, smeenai, compnerd, phosek Reviewed By: beanz Subscribers: wuzish, jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, mgorny, mehdi_amini, sbc100, jgravelle-google, hiraditya, aheejin, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, steven_wu, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, PkmX, jocewei, jsji, dang, Jim, lenary, s.egerton, pzheng, sameer.abuasal, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70179
* [InstCombine] add assert in SimplifyDemandedVectorElts and improve ↵Sanjay Patel2019-11-211-19/+22
| | | | readability; NFC
* [ARM,MVE] Add InstCombine rules for pred_i2v / pred_v2i.Simon Tatham2019-11-181-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If you're writing C code using the ACLE MVE intrinsics that passes the result of a vcmp as input to a predicated intrinsic, e.g. mve_pred16_t pred = vcmpeqq(v1, v2); v_out = vaddq_m(v_inactive, v3, v4, pred); then clang's codegen for the compare intrinsic will create calls to `@llvm.arm.mve.pred.v2i` to convert the output of `icmp` into an `mve_pred16_t` integer representation, and then the next intrinsic will call `@llvm.arm.mve.pred.i2v` to convert it straight back again. This will be visible in the generated code as a `vmrs`/`vmsr` pair that move the predicate value pointlessly out of `p0` and back into it again. To prevent that, I've added InstCombine rules to remove round trips of the form `v2i(i2v(x))` and `i2v(v2i(x))`. Also I've taught InstCombine about the known and demanded bits of those intrinsics. As a result, you now get just the generated code you wanted: vpt.u16 eq, q1, q2 vaddt.u16 q0, q3, q4 Reviewers: ostannard, MarkMurrayARM, dmgreen Reviewed By: dmgreen Subscribers: kristof.beyls, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70313
* [InstCombine] prevent crashing/assert on shift constant expression (PR44028)Sanjay Patel2019-11-171-1/+2
| | | | | The binary operator cast implies an instruction, but the matcher for shift does not: https://bugs.llvm.org/show_bug.cgi?id=44028
* [InstCombine] Canonicalize ssub.with.overflow with clamp to ssub.satDavid Green2019-11-171-16/+51
| | | | | | Working on top of D69252, this adds canonicalisation patterns for ssub.with.overflow to ssub.sats. Differential Revision: https://reviews.llvm.org/D69753
* [InstCombine] Canonicalize sadd.with.overflow with clamp to sadd.satDavid Green2019-11-171-1/+58
| | | | | | | | | | | | | This adds to D69245, adding extra signed patterns for folding from a sadd_with_overflow to a sadd_sat. These are more complex than the unsigned patterns, as the overflow can occur in either direction. For the add case, the positive overflow can only occur if both of the values are positive (same for both the values being negative). So there is an extra select on whether to use the positive or negative overflow limit. Differential Revision: https://reviews.llvm.org/D69252
* [InstCombine] Don't use getFirstNonPHI in FoldIntegerTypedPHIFrancis Visoiu Mistrih2019-11-141-4/+5
| | | | | | | | | | | | | | | | | | | getFirstNonPHI iterates over all the instructions in a block until it finds a non-PHI. Then, the loop starts from the beginning of the block and goes through all the instructions until it reaches the instruction found by getFirstNonPHI. Instead of doing that, just stop when a non-PHI is found. This reduces the compile-time of a test case discussed in https://reviews.llvm.org/D47023 by 13x. Not entirely sure how to come up with a test case for this since it's a compile time issue that would significantly slow down running the tests. Differential Revision: https://reviews.llvm.org/D70016
* Add missing includes needed to prune LLVMContext.h include, NFCReid Kleckner2019-11-141-1/+2
| | | | | These are a pre-requisite to removing #include "llvm/Support/Options.h" from LLVMContext.h: https://reviews.llvm.org/D70280
* [InstCombine] remove duplicate code for simplifying a shuffle; NFCISanjay Patel2019-11-141-7/+0
| | | | | The transform is already handled by InstSimplify or earlier in InstCombine, so trying to do it again is not necessary.
* Revert "[InstCombine] Fold PHIs with equal incoming pointers"Daniil Suchkov2019-11-142-70/+0
| | | | | This reverts commit a2f6ae9abffcba260c22bb235879f0576bf3b783. It is reverted due to clang-cmake-armv7-selfhost buildbot failure.
* [InstCombine] Fold PHIs with equal incoming pointersDaniil Suchkov2019-11-142-0/+70
| | | | | | | | | | | | | | | | | | | | | | | | This is a resubmission of bbb29738b58aaf6f6518269abdcf8f64131665a9 that was reverted due to clang tests failures. It includes the fix and additional IR tests for the missed case. Summary: In case when all incoming values of a PHI are equal pointers, this transformation inserts a definition of such a pointer right after definition of the base pointer and replaces with this value both PHI and all it's incoming pointers. Primary goal of this transformation is canonicalization of this pattern in order to enable optimizations that can't handle PHIs. Non-inbounds pointers aren't currently supported. Reviewers: spatel, RKSimon, lebedev.ri, apilipenko Reviewed By: apilipenko Tags: #llvm Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D68128
* Sink all InitializePasses.h includesReid Kleckner2019-11-131-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This file lists every pass in LLVM, and is included by Pass.h, which is very popular. Every time we add, remove, or rename a pass in LLVM, it caused lots of recompilation. I found this fact by looking at this table, which is sorted by the number of times a file was changed over the last 100,000 git commits multiplied by the number of object files that depend on it in the current checkout: recompiles touches affected_files header 342380 95 3604 llvm/include/llvm/ADT/STLExtras.h 314730 234 1345 llvm/include/llvm/InitializePasses.h 307036 118 2602 llvm/include/llvm/ADT/APInt.h 213049 59 3611 llvm/include/llvm/Support/MathExtras.h 170422 47 3626 llvm/include/llvm/Support/Compiler.h 162225 45 3605 llvm/include/llvm/ADT/Optional.h 158319 63 2513 llvm/include/llvm/ADT/Triple.h 140322 39 3598 llvm/include/llvm/ADT/StringRef.h 137647 59 2333 llvm/include/llvm/Support/Error.h 131619 73 1803 llvm/include/llvm/Support/FileSystem.h Before this change, touching InitializePasses.h would cause 1345 files to recompile. After this change, touching it only causes 550 compiles in an incremental rebuild. Reviewers: bkramer, asbirlea, bollu, jdoerfert Differential Revision: https://reviews.llvm.org/D70211
* [InstCombine] propagate fast-math-flags (FMF) to select when inverting ↵Sanjay Patel2019-11-131-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | fcmp+select As noted by the FIXME comment, this is not correct based on our current FMF semantics. We should be propagating FMF from the final value in a sequence (in this case the 'select'). So the behavior even without this patch is wrong, but we did not allow FMF on 'select' until recently. But if we do the correct thing right now in this patch, we'll inevitably introduce regressions because we have not wired up FMF propagation for 'phi' and 'select' in other passes (like SimplifyCFG) or other places in InstCombine. I'm not seeing a better incremental way to make progress. That said, the potential extra damage over the existing wrong behavior from this patch is very limited. AFAIK, the only way to have different FMF on IR in the same function is if we have LTO inlined IR from 2 modules that were compiled using different fast-math settings. As seen in the tests, we may actually see some improvements with this patch because adding the FMF to the 'select' allows matching to min/max intrinsics that were previously missed (in the common case, the 'fcmp' and 'select' should have identical FMF to begin with). Next steps in the transition: Make similar changes in instcombine as needed. Enable phi-to-select FMF propagation in SimplifyCFG. Remove dependencies on fcmp with FMF. Deprecate FMF on fcmp. Differential Revision: https://reviews.llvm.org/D69720
* [InstCombine] Avoid moving ops that do restrict undef across shuffles.Florian Hahn2019-11-131-1/+3
| | | | | | | | | | | | | | | | | | | I think we have to be a bit more careful when it comes to moving ops across shuffles, if the op does restrict undef. For example, without this patch, we would move 'and %v, <0, 0, -1, -1>' over a 'shufflevector %a, undef, <undef, undef, 1, 2>'. As a result, the first 2 lanes of the result are undef after the combine, but they really should be 0, unless I am missing something. For ops that do fold to undef on undef operands, the current behavior should be fine. I've add conservative check OpDoesRestrictUndef, maybe there's a better existing utility? Reviewers: spatel, RKSimon, lebedev.ri Reviewed By: spatel Differential Revision: https://reviews.llvm.org/D70093
* Temporarily revert "[InstCombine] Fold PHIs with equal incoming pointers"Daniil Suchkov2019-11-132-65/+0
| | | | | | Revert due to sanitizer-windows buildbot failure. This reverts commit bbb29738b58aaf6f6518269abdcf8f64131665a9.
* [InstCombine] Fold PHIs with equal incoming pointersDaniil Suchkov2019-11-132-0/+65
| | | | | | | | | | | | | | | | | | | In case when all incoming values of a PHI are equal pointers, this transformation inserts a definition of such a pointer right after definition of the base pointer and replaces with this value both PHI and all it's incoming pointers. Primary goal of this transformation is canonicalization of this pattern in order to enable optimizations that can't handle PHIs. Non-inbounds pointers aren't currently supported. Reviewers: spatel, RKSimon, lebedev.ri, apilipenko Reviewed By: apilipenko Tags: #llvm Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D68128
* [InstCombine] Skip scalable vectors in combineLoadToOperationTypeDiana Picus2019-11-121-0/+1
| | | | | | | | | | | | | | | | Don't try to canonicalize loads to scalable vector types to loads of integers. This removes one assertion when trying to use a TypeSize as a parameter to DataLayout::isLegalInteger. It does not handle the second part of the function (which looks at bitcasts). This patch also contains a NFC fix for Load Analysis, where a variable initialization that would cause the same assertion is moved closer to its use. This allows us to run the new test for InstCombine without having to teach LocationSize to play nicely with scalable vectors. Differential Revision: https://reviews.llvm.org/D70075
* Add InstCombine/InstructionSimplify support for Freeze Instructionaqjune2019-11-122-0/+10
| | | | | | | | | | | | | | | Summary: - Add llvm::SimplifyFreezeInst - Add InstCombiner::visitFreeze - Add llvm tests Reviewers: majnemer, sanjoy, reames, lebedev.ri, spatel Reviewed By: reames, lebedev.ri Subscribers: reames, lebedev.ri, filcab, regehr, trentxintong, llvm-commits Differential Revision: https://reviews.llvm.org/D29013
* Revert "[InstCombine] avoid crash from deleting an instruction that still ↵Sanjay Patel2019-11-111-18/+4
| | | | | | | | has uses (PR43723) (3rd try)" This reverts commit 3db8a3ef86e7b3331ab466a78c10a62be9e69829. This caused a different memory-sanitizer failure than earlier attempts, but it's still not right.
* [InstCombine] avoid crash from deleting an instruction that still has uses ↵Sanjay Patel2019-11-111-4/+18
| | | | | | | | | | | | | | | | | | | | | (PR43723) (3rd try) Re-try because earlier attempts were reverted due to use-after-free. Hopefully, diagnosed correctly this time - we replace/remove the invariant.start first rather than the invariant.end to avoid angering worklist-based iteration. We gather a set of white-listed instructions in isAllocSiteRemovable() and then replace/erase them. But we don't know in general if the instructions in the set have uses amongst themselves, so order of deletion makes a difference. There's already a special-case for the llvm.objectsize intrinsic, so add another for llvm.invariant.start. Should fix: https://bugs.llvm.org/show_bug.cgi?id=43723 Differential Revision: https://reviews.llvm.org/D69977
* [InstCombine] Simplify binary op when only one operand is a selectJay Foad2019-11-111-0/+10
| | | | | | | | | | | | | | | | | | | | | | Summary: SimplifySelectsFeedingBinaryOp simplified binary ops when both operands were selects with the same condition. This patch extends it to handle these cases where only one operand is a select: X op (C ? P : Q) -> C ? (X op P) : (X op Q) // if X op P and X op Q both simplify (C ? P : Q) op Y -> C ? (P op Y) : (Q op Y) // if P op Y and Q op Y both simplify For example: X *fast (C ? 1.0 : 0.0) -> C ? X : 0.0 Reviewers: mcberg2017, majnemer, craig.topper, qcolombet, mcrosier Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64713
* [InstCombine] Turn (extractelement <1 x i64/double> (bitcast (x86_mmx))) ↵Craig Topper2019-11-101-0/+7
| | | | | | | | | | | | | into a single bitcast from x86_mmx to i64/double. The _m64 type is represented in IR as <1 x i64>. The x86-64 ABI on Linux passes <1 x i64> as a double. MMX intrinsics use x86_mmx type in IR.These things result in a lot of bitcasts in mmx code. There's another instcombine that tries to turn bitcast <1 x i64> to double into extractelement and a bitcast. The combine here tries to reverse this extractelement conversion if we see an mmx type.
* Revert "[InstCombine] avoid crash from deleting an instruction that still ↵Sanjay Patel2019-11-101-20/+4
| | | | | | | has uses (PR43723) (2nd try)" This reverts commit 56b2aee1875a1ee47ddf859a6584f8728787fb7b. Still causes a use-after-free on sanitizer bots.
OpenPOWER on IntegriCloud