summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/InstCombine/InstCombineSimplifyDemanded.cpp
Commit message (Collapse)AuthorAgeFilesLines
* function names start with a lowercase letter; NFCSanjay Patel2016-02-011-1/+1
| | | | llvm-svn: 259425
* [InstCombine] Teach SimplifyDemandedVectorElts how to handle ConstantVector ↵Andrea Di Biagio2015-10-061-1/+7
| | | | | | | | | | | | | | | | | | | | | | select masks with ConstantExpr elements (PR24922) If the mask of a select instruction is a ConstantVector, method SimplifyDemandedVectorElts iterates over the mask elements to identify which values are selected from the select inputs. Before this patch, method SimplifyDemandedVectorElts always used method Constant::isNullValue() to check if a value in the mask was zero. Unfortunately that method always returns false when called on a ConstantExpr. This patch fixes the problem in SimplifyDemandedVectorElts by adding an explicit check for ConstantExpr values. Now, if a value in the mask is a ConstantExpr, we avoid calling isNullValue() on it. Fixes PR24922. Differential Revision: http://reviews.llvm.org/D13219 llvm-svn: 249390
* [InstCombine] Improve Vector Demanded Bits Through BitcastsSimon Pilgrim2015-09-291-35/+34
| | | | | | | | | | | | Currently SimplifyDemandedVectorElts can only peek through bitcasts if the vectors have the same number of elements. This patch fixes and enables some existing (disabled) code to support bitcasting to vectors with more/fewer elements. It currently only accepts cases when vectors alias cleanly (i.e. number of elements are an exact multiple of the other vector). This was added to improve the demanded vector elements support for SSE vector shifts which require the __m128i (<2 x i64>) argument type to be bitcast to the vector type for the builtin shift. I've added extra tests for various additional bitcasts. Differential Revision: http://reviews.llvm.org/D12935 llvm-svn: 248784
* [InstCombine] Added vector demanded bits support for SSE4A EXTRQ/INSERTQ ↵Simon Pilgrim2015-09-171-1/+10
| | | | | | | | | | instructions The SSE4A instructions EXTRQ/INSERTQ only use the lower 64-bits (or less) for many of their input vector operands and all of them have undefined upper 64-bits results. Differential Revision: http://reviews.llvm.org/D12680 llvm-svn: 247934
* Add support for floating-point minnum and maxnumJames Molloy2015-08-111-1/+1
| | | | | | | | | | | | | | | | | The select pattern recognition in ValueTracking (as used by InstCombine and SelectionDAGBuilder) only knew about integer patterns. This teaches it about minimum and maximum operations. matchSelectPattern() has been extended to return a struct containing the existing Flavor and a new enum defining the pattern's behavior when given one NaN operand. C minnum() is defined to return the non-NaN operand in this case, but the idiomatic C "a < b ? a : b" would return the NaN operand. ARM and AArch64 at least have different instructions for these different cases. llvm-svn: 244580
* Reapply r237539 with a fix for the Chromium build.James Molloy2015-05-201-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make sure if we're truncating a constant that would then be sign extended that the sign extension of the truncated constant is the same as the original constant. > Canonicalize min/max expressions correctly. > > This patch introduces a canonical form for min/max idioms where one operand > is extended or truncated. This often happens when the other operand is a > constant. For example: > > %1 = icmp slt i32 %a, i32 0 > %2 = sext i32 %a to i64 > %3 = select i1 %1, i64 %2, i64 0 > > Would now be canonicalized into: > > %1 = icmp slt i32 %a, i32 0 > %2 = select i1 %1, i32 %a, i32 0 > %3 = sext i32 %2 to i64 > > This builds upon a patch posted by David Majenemer > (https://www.marc.info/?l=llvm-commits&m=143008038714141&w=2). That pass > passively stopped instcombine from ruining canonical patterns. This > patch additionally actively makes instcombine canonicalize too. > > Canonicalization of expressions involving a change in type from int->fp > or fp->int are not yet implemented. llvm-svn: 237821
* Revert r237539: "Reapply r237520 with another fix for infinite looping"Hans Wennborg2015-05-191-7/+0
| | | | | | This caused PR23583. llvm-svn: 237739
* Reapply r237520 with another fix for infinite loopingJames Molloy2015-05-171-0/+7
| | | | | | | | | SimplifyDemandedBits was "simplifying" a constant by removing just sign bits. This caused a canonicalization race between different parts of instcombine. Fix and regression test added - third time lucky? llvm-svn: 237539
* InstCombineSimplifyDemanded: Remove nsw/nuw flags when optimizing demanded bitsMatthias Braun2015-04-301-102/+15
| | | | | | | | | | | | | | | | | | | | | | | | | When optimizing demanded bits of the operands of an Add we have to remove the nsw/nuw flags as we have no guarantee anymore that we don't wrap. This is legal here because the top bit is not demanded. In fact this operaion was already performed but missed in the case of an Add with a constant on the right side. To fix this this patch refactors the code to unify the code paths in SimplifyDemandedUseBits() handling of Add/Sub: - The transformation of Add->Or is removed from the simplify demand code because the equivalent transformation exists in InstCombiner::visitAdd() - KnownOnes/KnownZero are not adjusted for Add x, C anymore as computeKnownBits() already performs these computations. - The simplification of the operands is unified. In this new version constant on the right side of a Sub are shrunk now as I could not find a reason why not to do so. - The special case for clearing nsw/nuw in ShrinkDemandedConstant() is not necessary anymore as the caller does that already. Differential Revision: http://reviews.llvm.org/D9415 llvm-svn: 236269
* InstCombine: Move Sub->Xor rule from SimplifyDemanded to InstCombineMatthias Braun2015-04-301-10/+0
| | | | | | | | | | The rule that turns a sub to xor if the LHS is 2^n-1 and the remaining bits are known zero, does not use the demanded bits at all: Move it to the normal InstCombine code path. Differential Revision: http://reviews.llvm.org/D9417 llvm-svn: 236268
* [InstCombine] Use a more targeted fix instead of r235544David Majnemer2015-04-221-9/+8
| | | | | | | | | Only clear out the NSW/NUW flags if we are optimizing 'add'/'sub' while taking advantage that the sign bit is not set. We do this optimization to further shrink the mask but shrinking the mask isn't NSW/NUW preserving in this case. llvm-svn: 235558
* [InstCombine] Clear out nsw/nuw if we modify computation in the chainDavid Majnemer2015-04-221-3/+10
| | | | | | | | | | | | An nsw/nuw operation relies on the values feeding into it to not overflow if 'poison' is not to be produced. This means that optimizations which make modifications to the bottom of a chain (like SimplifyDemandedBits) must strip out nsw/nuw if they cannot ensure that they will be preserved. This fixes PR23309. llvm-svn: 235544
* DataLayout is mandatory, update the API to reflect it with references.Mehdi Amini2015-03-101-76/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Now that the DataLayout is a mandatory part of the module, let's start cleaning the codebase. This patch is a first attempt at doing that. This patch is not exactly NFC as for instance some places were passing a nullptr instead of the DataLayout, possibly just because there was a default value on the DataLayout argument to many functions in the API. Even though it is not purely NFC, there is no change in the validation. I turned as many pointer to DataLayout to references, this helped figuring out all the places where a nullptr could come up. I had initially a local version of this patch broken into over 30 independant, commits but some later commit were cleaning the API and touching part of the code modified in the previous commits, so it seemed cleaner without the intermediate state. Test Plan: Reviewers: echristo Subscribers: llvm-commits From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 231740
* [PM] Rename InstCombine.h to InstCombineInternal.h in preparation forChandler Carruth2015-01-221-1/+1
| | | | | | | | | | | | | | | | creating a non-internal header file for the InstCombine pass. I thought about calling this InstCombiner.h or in some way more clearly associating it with the InstCombiner clas that it is primarily defining, but there are several other utility interfaces defined within this for InstCombine. If, in the course of refactoring, those end up moving elsewhere or going away, it might make more sense to make this the combiner's header alone. Naturally, this is a bikeshed to a certain degree, so feel free to lobby for a different shade of paint if this name just doesn't suit you. llvm-svn: 226783
* Add additional patterns for @llvm.assume in ValueTrackingHal Finkel2014-09-071-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This builds on r217342, which added the infrastructure to compute known bits using assumptions (@llvm.assume calls). That original commit added only a few patterns (to catch common cases related to determining pointer alignment); this change adds several other patterns for simple cases. r217342 contained that, for assume(v & b = a), bits in the mask that are known to be one, we can propagate known bits from the a to v. It also had a known-bits transfer for assume(a = b). This patch adds: assume(~(v & b) = a) : For those bits in the mask that are known to be one, we can propagate inverted known bits from the a to v. assume(v | b = a) : For those bits in b that are known to be zero, we can propagate known bits from the a to v. assume(~(v | b) = a): For those bits in b that are known to be zero, we can propagate inverted known bits from the a to v. assume(v ^ b = a) : For those bits in b that are known to be zero, we can propagate known bits from the a to v. For those bits in b that are known to be one, we can propagate inverted known bits from the a to v. assume(~(v ^ b) = a) : For those bits in b that are known to be zero, we can propagate inverted known bits from the a to v. For those bits in b that are known to be one, we can propagate known bits from the a to v. assume(v << c = a) : For those bits in a that are known, we can propagate them to known bits in v shifted to the right by c. assume(~(v << c) = a) : For those bits in a that are known, we can propagate them inverted to known bits in v shifted to the right by c. assume(v >> c = a) : For those bits in a that are known, we can propagate them to known bits in v shifted to the right by c. assume(~(v >> c) = a) : For those bits in a that are known, we can propagate them inverted to known bits in v shifted to the right by c. assume(v >=_s c) where c is non-negative: The sign bit of v is zero assume(v >_s c) where c is at least -1: The sign bit of v is zero assume(v <=_s c) where c is negative: The sign bit of v is one assume(v <_s c) where c is non-positive: The sign bit of v is one assume(v <=_u c): Transfer the known high zero bits assume(v <_u c): Transfer the known high zero bits (if c is know to be a power of 2, transfer one more) A small addition to InstCombine was necessary for some of the test cases. The problem is that when InstCombine was simplifying and, or, etc. it would fail to check the 'do I know all of the bits' condition before checking less specific conditions and would not fully constant-fold the result. I'm not sure how to trigger this aside from using assumptions, so I've just included the change here. llvm-svn: 217343
* Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)Hal Finkel2014-09-071-15/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change, which allows @llvm.assume to be used from within computeKnownBits (and other associated functions in ValueTracking), adds some (optional) parameters to computeKnownBits and friends. These functions now (optionally) take a "context" instruction pointer, an AssumptionTracker pointer, and also a DomTree pointer, and most of the changes are just to pass this new information when it is easily available from InstSimplify, InstCombine, etc. As explained below, the significant conceptual change is that known properties of a value might depend on the control-flow location of the use (because we care that the @llvm.assume dominates the use because assumptions have control-flow dependencies). This means that, when we ask if bits are known in a value, we might get different answers for different uses. The significant changes are all in ValueTracking. Two main changes: First, as with the rest of the code, new parameters need to be passed around. To make this easier, I grouped them into a structure, and I made internal static versions of the relevant functions that take this structure as a parameter. The new code does as you might expect, it looks for @llvm.assume calls that make use of the value we're trying to learn something about (often indirectly), attempts to pattern match that expression, and uses the result if successful. By making use of the AssumptionTracker, the process of finding @llvm.assume calls is not expensive. Part of the structure being passed around inside ValueTracking is a set of already-considered @llvm.assume calls. This is to prevent a query using, for example, the assume(a == b), to recurse on itself. The context and DT params are used to find applicable assumptions. An assumption needs to dominate the context instruction, or come after it deterministically. In this latter case we only handle the specific case where both the assumption and the context instruction are in the same block, and we need to exclude assumptions from being used to simplify their own ephemeral values (those which contribute only to the assumption) because otherwise the assumption would prove its feeding comparison trivial and would be removed. This commit adds the plumbing and the logic for a simple masked-bit propagation (just enough to write a regression test). Future commits add more patterns (and, correspondingly, more regression tests). llvm-svn: 217342
* InstCombine: Don't unconditionally preserve 'nuw' when shrinking constantsDavid Majnemer2014-08-221-6/+12
| | | | | | | | | | | | Consider: %add = add nuw i32 %a, -16777216 %and = and i32 %add, 255 Regardless of whether or not we demand the sign bit of %add, we cannot replace -16777216 with 2130706432 without also removing 'nuw' from the instruction. llvm-svn: 216273
* InstCombine: Don't unconditionally preserve 'nsw' when shrinking constantsDavid Majnemer2014-08-221-0/+8
| | | | | | | | | | | | | | Consider: %add = add nsw i32 %a, -16777216 %and = and i32 %add, 255 Regardless of whether or not we demand the sign bit of %add, we cannot replace -16777216 with 2130706432 without also removing 'nsw' from the instruction. This fixes PR20377. llvm-svn: 216261
* Rename ComputeMaskedBits to computeKnownBits. "Masked" has beenJay Foad2014-05-141-13/+13
| | | | | | inappropriate since it lost its Mask parameter in r154011. llvm-svn: 208811
* [C++] Use 'nullptr'.Craig Topper2014-04-281-1/+1
| | | | llvm-svn: 207394
* [C++] Use 'nullptr'. Transforms edition.Craig Topper2014-04-251-27/+27
| | | | llvm-svn: 207196
* [Modules] Fix potential ODR violations by sinking the DEBUG_TYPEChandler Carruth2014-04-221-1/+2
| | | | | | | | | | | | | | | | | definition below all of the header #include lines, lib/Transforms/... edition. This one is tricky for two reasons. We again have a couple of passes that define something else before the includes as well. I've sunk their name macros with the DEBUG_TYPE. Also, InstCombine contains headers that need DEBUG_TYPE, so now those headers #define and #undef DEBUG_TYPE around their code, leaving them well formed modular headers. Fixing these headers was a large motivation for all of these changes, as "leaky" macros of this form are hard on the modules implementation. llvm-svn: 206844
* [Modules] Sink all the DEBUG_TYPE defines for InstCombine out of theChandler Carruth2014-04-211-1/+1
| | | | | | | | | | | header files and into the cpp files. These files will require more touches as the header files actually use DEBUG(). Eventually, I'll have to introduce a matched #define and #undef of DEBUG_TYPE for the header files, but that comes as step N of many to clean all of this up. llvm-svn: 206777
* [Modules] Move the LLVM IR pattern match header into the IR library, itChandler Carruth2014-03-041-1/+1
| | | | | | obviously is coupled to the IR. llvm-svn: 202818
* Rename many DataLayout variables from TD to DL.Rafael Espindola2014-02-211-2/+2
| | | | | | | | | I am really sorry for the noise, but the current state where some parts of the code use TD (from the old name: TargetData) and other parts use DL makes it hard to write a patch that changes where those variables come from and how they are passed along. llvm-svn: 201827
* Remove x86_sse42_crc32_64_8 intrinsic. It has no functional difference from ↵Craig Topper2013-10-151-1/+0
| | | | | | x86_sse42_crc32_32_8 and was not mapped to a clang builtin. I'm not even sure why this form of the instruction is even called out explicitly in the docs. Also add AutoUpgrade support to convert it into the other intrinsic with appropriate trunc and zext. llvm-svn: 192672
* InstCombine: Check for zero shift amounts before subtracting one causing ↵Benjamin Kramer2013-08-301-10/+15
| | | | | | | | | integer overflow. PR17026. Also avoid undefined shifts and shift amounts larger than 64 bits (those are always undef because we can't represent integer types that large). llvm-svn: 189672
* InstCombine: Don't just copy known bits from the first operand of an srem.Benjamin Kramer2013-05-091-1/+1
| | | | | | | That's obviously wrong. Conservatively restrict it to the sign bit, which matches the original intention of this analysis. Fixes PR15940. llvm-svn: 181518
* Move all of the header files which are involved in modelling the LLVM IRChandler Carruth2013-01-021-2/+2
| | | | | | | | | | | | | | | | | | | | | into their new header subdirectory: include/llvm/IR. This matches the directory structure of lib, and begins to correct a long standing point of file layout clutter in LLVM. There are still more header files to move here, but I wanted to handle them in separate commits to make tracking what files make sense at each layer easier. The only really questionable files here are the target intrinsic tablegen files. But that's a battle I'd rather not fight today. I've updated both CMake and Makefile build systems (I think, and my tests think, but I may have missed something). I've also re-sorted the includes throughout the project. I'll be committing updates to Clang, DragonEgg, and Polly momentarily. llvm-svn: 171366
* Remove trailing whitespaceCraig Topper2012-12-221-126/+126
| | | | llvm-svn: 170990
* - Fix a problematic way in creating all-the-1 APInt.Shuxin Yang2012-12-121-2/+4
| | | | | | - Propagate "exact" bit of [l|a]shr instruction. llvm-svn: 169942
* For rdar://12329730, last piece.Shuxin Yang2012-12-041-1/+14
| | | | | | | | | | | | | | | | | | | | | This change attempts to simplify (X^Y) -> X or Y in the user's context if we know that only bits from X or Y are demanded. A minimized case is provided bellow. This change will simplify "t>>16" into "var1 >>16". ============================================================= unsigned foo (unsigned val1, unsigned val2) { unsigned t = val1 ^ 1234; return (t >> 16) | t; // NOTE: t is used more than once. } ============================================================= Note that if the "t" were used only once, the expression would be finally optimized as well. However, with with this change, the optimization will take place earlier. Reviewed by Nadav, Thanks a lot! llvm-svn: 169317
* rdar://12329730 (2nd part, revised)Shuxin Yang2012-12-041-1/+2
| | | | | | | The type of shirt-right (logical or arithemetic) should remain unchanged when transforming "X << C1 >> C2" into "X << (C1-C2)" llvm-svn: 169209
* rdar://12329730 (2nd part)Shuxin Yang2012-12-041-1/+85
| | | | | | | | | | | This change tries to simmplify E1 = " X >> C1 << C2" into : - E2 = "X << (C2 - C1)" if C2 > C1, or - E2 = "X >> (C1 - C2)" if C1 > C2, or - E2 = X if C1 == C2. Reviewed by Nadav. Thanks! llvm-svn: 169182
* Move TargetData to DataLayout.Micah Villmow2012-10-081-1/+1
| | | | llvm-svn: 165402
* Revert 'Fix a typo 'iff' => 'if''. iff is an abreviation of if and only if. ↵Sylvestre Ledru2012-09-271-2/+2
| | | | | | See: http://en.wikipedia.org/wiki/If_and_only_if Commit 164767 llvm-svn: 164768
* Fix a typo 'iff' => 'if'Sylvestre Ledru2012-09-271-2/+2
| | | | llvm-svn: 164767
* Simplify demanded bits of select sources where the condition is a constant ↵Pete Cooper2012-07-261-0/+23
| | | | | | vector llvm-svn: 160835
* Teach SimplifyDemandedBits how to look through fpext and fptrunc to simplify ↵Pete Cooper2012-07-261-0/+6
| | | | | | their operand llvm-svn: 160823
* Back out r160101 and instead implement a dag combine to recover from ↵Evan Cheng2012-07-171-7/+0
| | | | | | instcombine transformation. llvm-svn: 160387
* Instcombine was transforming:Evan Cheng2012-07-121-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | %shr = lshr i64 %key, 3 %0 = load i64* %val, align 8 %sub = add i64 %0, -1 %and = and i64 %sub, %shr ret i64 %and to: %shr = lshr i64 %key, 3 %0 = load i64* %val, align 8 %sub = add i64 %0, 2305843009213693951 %and = and i64 %sub, %shr ret i64 %and The demanded bit optimization is actually a pessimization because add -1 would be codegen'ed as a sub 1. Teach the demanded constant shrinking optimization to check for negated constant to make sure it is actually reducing the width of the constant. rdar://11793464 llvm-svn: 160101
* Always compute all the bits in ComputeMaskedBits.Rafael Espindola2012-04-041-16/+10
| | | | | | | | This allows us to keep passing reduced masks to SimplifyDemandedBits, but know about all the bits if SimplifyDemandedBits fails. This allows instcombine to simplify cases like the one in the included testcase. llvm-svn: 154011
* continue making the world safe for ConstantDataVector. At this point,Chris Lattner2012-01-271-1/+1
| | | | | | | we should (theoretically optimize and codegen ConstantDataVector as well as ConstantVector. llvm-svn: 149116
* use Constant::getAggregateElement to simplify a bunch of code.Chris Lattner2012-01-251-42/+22
| | | | llvm-svn: 148934
* use ConstantVector::getSplat in a few places.Chris Lattner2012-01-251-2/+2
| | | | llvm-svn: 148929
* basic instcombine support for CDS.Chris Lattner2012-01-241-11/+24
| | | | llvm-svn: 148806
* Teach instcombine all sorts of great stuff about shifts that have exact, nuw orNick Lewycky2012-01-041-2/+3
| | | | | | nsw bits on them. llvm-svn: 147528
* InstCombine: Canonicalize (2^n)-1 - x into (2^n)-1 ^ x iff x is known to be ↵Benjamin Kramer2011-12-241-0/+11
| | | | | | | | | | | smaller than 2^n. This has the obvious advantage of being commutable and is always a win on x86 because const - x wastes a register there. On less weird architectures this may lead to a regression because other arithmetic doesn't fuse with it anymore. I'll address that problem in a followup. llvm-svn: 147254
* Stop emitting instructions with the name "tmp" they eat up memory and have ↵Benjamin Kramer2011-09-271-6/+3
| | | | | | | | to be uniqued, without any benefit. If someone prefers %tmp42 to %42, run instnamer. llvm-svn: 140634
* Make demanded-elt simplification for shufflevector slightly stronger. ↵Eli Friedman2011-09-151-0/+3
| | | | | | Spotted by inspection. llvm-svn: 139768
OpenPOWER on IntegriCloud