summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/InstCombine/InstCombineCasts.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Revert r255137.Akira Hatanaka2015-12-101-39/+0
| | | | | | This commit broke apple's internal bot. llvm-svn: 255227
* [InstCombine] fold bitcasts around an extractelement (2nd try)Sanjay Patel2015-12-091-0/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a redo of r255124 (reverted at r255126) with an added check for a scalar destination type and an added test for the failure seen in Clang's test/CodeGen/vector.c. The extra test shows a different missing optimization. Original commit message: Example: bitcast (extractelement (bitcast <2 x float> %X to <2 x i32>), 1) to float ---> extractelement <2 x float> %X, i32 1 This is part of fixing PR25543: https://llvm.org/bugs/show_bug.cgi?id=25543 The next step will be to generalize this fold: trunc ( lshr ( bitcast X) ) -> extractelement (X) Ie, I'm hoping to replace the existing transform of: bitcast ( trunc ( lshr ( bitcast X))) added by: http://reviews.llvm.org/rL112232 with 2 less specific transforms to catch the case in the bug report. Differential Revision: http://reviews.llvm.org/D14879 llvm-svn: 255137
* Revert "[InstCombine] fold bitcasts around an extractelement"Mehdi Amini2015-12-091-37/+0
| | | | | | | | | This reverts commit r255124. Broke http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/4193/steps/test/logs/stdio From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 255126
* [InstCombine] fold bitcasts around an extractelementSanjay Patel2015-12-091-0/+37
| | | | | | | | | | | | | | | | | | | | | | | | Example: bitcast (extractelement (bitcast <2 x float> %X to <2 x i32>), 1) to float ---> extractelement <2 x float> %X, i32 1 This is part of fixing PR25543: https://llvm.org/bugs/show_bug.cgi?id=25543 The next step will be to generalize this fold: trunc ( lshr ( bitcast X) ) -> extractelement (X) Ie, I'm hoping to replace the existing transform of: bitcast ( trunc ( lshr ( bitcast X))) added by: http://reviews.llvm.org/rL112232 with 2 less specific transforms to catch the case in the bug report. Differential Revision: http://reviews.llvm.org/D14879 llvm-svn: 255124
* fix typo; NFCSanjay Patel2015-11-211-1/+1
| | | | llvm-svn: 253785
* [InstCombine] refactor optimizeIntToFloatBitCast() ; NFCISanjay Patel2015-11-181-38/+29
| | | | | | | | | | | | | | | The logic for handling the pattern without a shift is identical to the logic for handling the pattern with a shift if you set the shift amount to zero for the former. This should make it easier to see that we probably don't even need optimizeIntToFloatBitCast(). If we call something like foldVecTruncToExtElt() from visitTrunc(), we'll solve PR25543: https://llvm.org/bugs/show_bug.cgi?id=25543 llvm-svn: 253403
* fix typos; NFCSanjay Patel2015-11-171-2/+2
| | | | llvm-svn: 253359
* use local variables; NFCISanjay Patel2015-11-171-7/+7
| | | | llvm-svn: 253356
* InstCombine: Remove ilist iterator implicit conversions, NFCDuncan P. N. Exon Smith2015-10-131-1/+1
| | | | | | | Stop relying on implicit conversions of ilist iterators in LLVMInstCombine. No functionality change intended. llvm-svn: 250183
* There is a trunc(lshr (zext A), Cst) optimization in InstCombineCasts thatJakub Kuderski2015-09-101-0/+20
| | | | | | | | | | | removes cast by performing the lshr on smaller types. However, currently there is no trunc(lshr (sext A), Cst) variant. This patch add such optimization by transforming trunc(lshr (sext A), Cst) to ashr A, Cst. Differential Revision: http://reviews.llvm.org/D12520 llvm-svn: 247271
* Revert trunc(lshr (sext A), Cst) to ashr A, CstDavid Majnemer2015-09-091-20/+0
| | | | | | This reverts commit r246997, it introduced a regression (PR24763). llvm-svn: 247180
* function names start with a lower case letter; NFCSanjay Patel2015-09-091-54/+54
| | | | llvm-svn: 247150
* don't repeat function names in comments; NFCSanjay Patel2015-09-091-35/+32
| | | | llvm-svn: 247148
* There is a trunc(lshr (zext A), Cst) optimization in InstCombineCasts thatJakub Kuderski2015-09-081-0/+20
| | | | | | | | | | | removes cast by performing the lshr on smaller types. However, currently there is no trunc(lshr (sext A), Cst) variant. This patch add such optimization by transforming trunc(lshr (sext A), Cst) to ashr A, Cst. Differential Revision: http://reviews.llvm.org/D12520 llvm-svn: 246997
* Add support for floating-point minnum and maxnumJames Molloy2015-08-111-2/+8
| | | | | | | | | | | | | | | | | 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/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-9/+0
| | | | | | This caused PR23583. llvm-svn: 237739
* Reapply r237520 with another fix for infinite loopingJames Molloy2015-05-171-0/+9
| | | | | | | | | 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
* Revert commits r237521 and r237520.James Molloy2015-05-161-9/+0
| | | | | | | | The AArch64 LNT bot is unhappy - I've found that the problem is in SimpliftDemandedBits, but that's going to require another code review so reverting in the meantime. llvm-svn: 237528
* Reapply r237453 with a fix for the test timeouts.James Molloy2015-05-161-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The test timeouts were due to instcombine fighting itself. Regression test added. Original log message: 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: 237520
* Convert PHI getIncomingValue() to foreach over incoming_values(). NFC.Pete Cooper2015-05-121-4/+4
| | | | | | | | We already had a method to iterate over all the incoming values of a PHI. This just changes all eligible code to use it. Ineligible code included anything which cared about the index, or was also trying to get the i'th incoming BB. llvm-svn: 237169
* [InstCombine] Create zero constants on demand.Benjamin Kramer2015-04-181-4/+2
| | | | | | No functional change intended. llvm-svn: 235257
* Recommit r233116 better: Remove a redundant instcombine involving bitcasts ↵David Blaikie2015-03-271-36/+0
| | | | | | | | | | | | of geps of bitcasts This just didn't need to be here at all, but the assertion I tried to add wasn't appropriate either - the circumstance isn't impossible, it's just not important to deal with it here - the gep-rooted version of this instcombine will handle this case, we don't need to duplicate it for the case where the gep happens to be used in a bitcast. llvm-svn: 233404
* Opaque Pointer Types: GEP API migrations to specify the gep type explicitlyDavid Blaikie2015-03-241-3/+5
| | | | | | | | | | | | | | | | | | | | | The changes to InstCombine (& SCEV) do seem a bit silly - it doesn't make anything obviously better to have the caller access the pointers element type (the thing I'm trying to remove) than the GEP itself, but it's a helpful migration step. This will allow me to more obviously lock down GEP (& Load, etc) API usage, then fix all the code that accesses pointer element types except the places that need to be removed (most of the InstCombines) anyway - at which point I'll need to just remove all that code because it won't be meaningful anymore (there will be no pointer types, so no bitcasts to combine) SCEV looks like it'll need some restructuring - we'll have to do a bit more work for GEP canonicalization, since it'll depend on how it's used if we can even manage to canonicalize it to a non-ugly GEP. I guess we can do some fun stuff like voting (do 2 out of 3 load from the GEP with a certain type that gives a pretty GEP? Does every typed use of the GEP use either a specific type or a generic type (i8*, etc)?) llvm-svn: 233131
* Revert "Remove an InstCombine that seems to have become redundant."David Blaikie2015-03-241-13/+28
| | | | | | | | Assertion fires in compiler-rt. Guess it does fire.. This reverts commit r233116. llvm-svn: 233121
* Remove an InstCombine that seems to have become redundant.David Blaikie2015-03-241-28/+13
| | | | | | | | Assert that this doesn't fire - I'll remove all of this later, but just leaving it in for a while in case this is firing & we just don't have test coverage. llvm-svn: 233116
* [opaque pointer type] IRBuilder gep migration progressDavid Blaikie2015-03-151-0/+5
| | | | llvm-svn: 232294
* DataLayout is mandatory, update the API to reflect it with references.Mehdi Amini2015-03-101-78/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* InstCombine: fold more cases of (fp_to_u/sint (u/sint_to_fp val))Mehdi Amini2015-02-161-22/+48
| | | | | | | Fixes radar 15486701. From: Fiona Glaser <fglaser@apple.com> llvm-svn: 229437
* [InstCombine] When canonicalizing gep indices, prefer zext when possiblePhilip Reames2015-02-141-0/+9
| | | | | | | | | | If we know that the sign bit of a value being sign extended is zero, we can use a zero extension instead. This is motivated by the fact that zero extensions are generally cheaper on x86 (and most other architectures?). We already apply a similar transform in DAGCombine, this just extends that to the IR level. This comes up when we eagerly canonicalize gep indices to the width of a machine register (i64 on x86_64). To do so, we insert sign extensions (sext) to promote smaller types. Differential Revision: http://reviews.llvm.org/D7255 llvm-svn: 229189
* [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
* [PM] Move TargetLibraryInfo into the Analysis library.Chandler Carruth2015-01-151-1/+1
| | | | | | | | | | | | | | | | While the term "Target" is in the name, it doesn't really have to do with the LLVM Target library -- this isn't an abstraction which LLVM targets generally need to implement or extend. It has much more to do with modeling the various runtime libraries on different OSes and with different runtime environments. The "target" in this sense is the more general sense of a target of cross compilation. This is in preparation for porting this analysis to the new pass manager. No functionality changed, and updates inbound for Clang and Polly. llvm-svn: 226078
* More code format fix from r224133, NFCSteven Wu2014-12-121-2/+1
| | | | llvm-svn: 224140
* Restructure code from r224097. NFCSteven Wu2014-12-121-12/+12
| | | | llvm-svn: 224133
* Fix another infinite loop in InstCombineSteven Wu2014-12-121-9/+12
| | | | | | | | | | | | | | | Summary: InstCombine infinite-loops for the testcase added It is because InstCombine is generating instructions that can be optimized by itself. Fix by not optimizing frem if the optimized type is the same as original type. rdar://problem/19150820 Reviewers: majnemer Differential Revision: http://reviews.llvm.org/D6634 llvm-svn: 224097
* InstCombine: Fix another infinite loop caused by visitFPTruncDavid Majnemer2014-11-181-5/+4
| | | | | | | | | | We would attempt to replace an frem's operand with the same operand. This would cause InstCombine to think real work was done, causing InstCombine to enter an infinite loop. This fixes the second part of PR21576. llvm-svn: 222265
* Revert "Revert r222040 because of bot failure."David Majnemer2014-11-181-6/+9
| | | | | | | This reverts commit r222203, reverting r222040 didn't end up turning the bot green. llvm-svn: 222261
* Revert r222040 because of bot failure.Manman Ren2014-11-181-9/+6
| | | | | | | http://lab.llvm.org:8080/green/job/clang-Rlto_master/298/ Hopefully, bot will be green. llvm-svn: 222203
* InstCombine: Fix infinite loop caused by visitFPTruncDavid Majnemer2014-11-141-6/+9
| | | | | | | | | | | We would attempt to replace a fptrunc of an frem with an identical fptrunc. This would cause the new fptrunc to be added to the worklist. Of course, this results in an infinite loop because we will keep visiting the newly created fptruncs. This fixes PR21576. llvm-svn: 222040
* InstCombine: Fix a combine assuming that icmp operands were integersDavid Majnemer2014-10-271-0/+4
| | | | | | | | | An icmp may have pointer arguments, it isn't limited to integers or vectors of integers. This fixes PR21388. llvm-svn: 220664
* Handle sqrt() shrinking in SimplifyLibCalls like any other callSanjay Patel2014-10-231-36/+0
| | | | | | | | | | | | | | | | | This patch removes a chunk of special case logic for folding (float)sqrt((double)x) -> sqrtf(x) in InstCombineCasts and handles it in the mainstream path of SimplifyLibCalls. No functional change intended, but I loosened the restriction on the existing sqrt testcases to allow for this optimization even without unsafe-fp-math because that's the existing behavior. I also added a missing test case for not shrinking the llvm.sqrt.f64 intrinsic in case the result is used as a double. Differential Revision: http://reviews.llvm.org/D5919 llvm-svn: 220514
* Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)Hal Finkel2014-09-071-34/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix comment in InstCombiner::visitAddrSpaceCast.Manuel Jacob2014-07-161-3/+3
| | | | | | | | In the original version of the patch the behaviour was like described in the comment. This behaviour was changed before committing it without updating the comment. llvm-svn: 213117
* Canonicalize addrspacecast ConstExpr between different pointer typesJingyue Wu2014-06-151-2/+4
| | | | | | | | | | | | | | | | | | As a follow-up to r210375 which canonicalizes addrspacecast instructions, this patch canonicalizes addrspacecast constant expressions. Given clang uses ConstantExpr::getAddrSpaceCast to emit addrspacecast cosntant expressions, this patch is also a step towards having the frontend emit canonicalized addrspacecasts. Piggyback a minor refactor in InstCombineCasts.cpp Update three affected tests in addrspacecast-alias.ll, access-non-generic.ll and constant-fold-gep.ll and added one new test in constant-fold-address-space-pointer.ll llvm-svn: 211004
* InstCombine: Canonicalize addrspacecast between different element typesJingyue Wu2014-06-061-1/+23
| | | | | | | | | | | | | | | | addrspacecast X addrspace(M)* to Y addrspace(N)* --> bitcast X addrspace(M)* to Y addrspace(M)* addrspacecast Y addrspace(M)* to Y addrspace(N)* Updat all affected tests and add several new tests in addrspacecast.ll. This patch is based on http://reviews.llvm.org/D2186 (authored by Matt Arsenault) with fixes and more tests. llvm-svn: 210375
* Rename ComputeMaskedBits to computeKnownBits. "Masked" has beenJay Foad2014-05-141-4/+4
| | | | | | inappropriate since it lost its Mask parameter in r154011. llvm-svn: 208811
* InstCombine: don't drop 'inalloca' in PromoteCastOfAllocation (PR19569)Hans Wennborg2014-04-281-0/+1
| | | | llvm-svn: 207426
* [C++] Use 'nullptr'. Transforms edition.Craig Topper2014-04-251-39/+39
| | | | 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-0/+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
OpenPOWER on IntegriCloud