summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/InstCombine/InstCombineCasts.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [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
* [C++11] Add range based accessors for the Use-Def chain of a Value.Chandler Carruth2014-03-091-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This requires a number of steps. 1) Move value_use_iterator into the Value class as an implementation detail 2) Change it to actually be a *Use* iterator rather than a *User* iterator. 3) Add an adaptor which is a User iterator that always looks through the Use to the User. 4) Wrap these in Value::use_iterator and Value::user_iterator typedefs. 5) Add the range adaptors as Value::uses() and Value::users(). 6) Update *all* of the callers to correctly distinguish between whether they wanted a use_iterator (and to explicitly dig out the User when needed), or a user_iterator which makes the Use itself totally opaque. Because #6 requires churning essentially everything that walked the Use-Def chains, I went ahead and added all of the range adaptors and switched them to range-based loops where appropriate. Also because the renaming requires at least churning every line of code, it didn't make any sense to split these up into multiple commits -- all of which would touch all of the same lies of code. The result is still not quite optimal. The Value::use_iterator is a nice regular iterator, but Value::user_iterator is an iterator over User*s rather than over the User objects themselves. As a consequence, it fits a bit awkwardly into the range-based world and it has the weird extra-dereferencing 'operator->' that so many of our iterators have. I think this could be fixed by providing something which transforms a range of T&s into a range of T*s, but that *can* be separated into another patch, and it isn't yet 100% clear whether this is the right move. However, this change gets us most of the benefit and cleans up a substantial amount of code around Use and User. =] llvm-svn: 203364
* [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
* Make some DataLayout pointers const.Rafael Espindola2014-02-241-1/+1
| | | | | | No functionality change. Just reduces the noise of an upcoming patch. llvm-svn: 202087
* Rename many DataLayout variables from TD to DL.Rafael Espindola2014-02-211-27/+27
| | | | | | | | | 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
* Fix known typosAlp Toker2014-01-241-2/+2
| | | | | | | Sweep the codebase for common typos. Includes some changes to visible function names that were misspelt. llvm-svn: 200018
* InstCombine: Modernize a bunch of cast combines.Benjamin Kramer2014-01-191-44/+23
| | | | | | Also make them vector-aware. llvm-svn: 199608
* Fix more instances of dropped fast math flags when optimizing FADD ↵Owen Anderson2014-01-181-4/+17
| | | | | | instructions. All found by inspection (aka grep). llvm-svn: 199528
* Do pointer cast simplifications on addrspacecastMatt Arsenault2014-01-141-1/+1
| | | | llvm-svn: 199254
* Remove a check for an illegal condition.Matt Arsenault2014-01-141-5/+0
| | | | | | Bitcasts can't be between address spaces anymore. llvm-svn: 199253
* Rein in overzealous InstCombine of fptrunc(OP(fpextend, fpextend)).Stephen Canon2013-11-281-26/+82
| | | | llvm-svn: 195934
* Apply the InstCombine fptrunc sqrt optimization to llvm.sqrtHal Finkel2013-11-161-6/+11
| | | | | | | | | | | | | | | | | | | InstCombine, in visitFPTrunc, applies the following optimization to sqrt calls: (fptrunc (sqrt (fpext x))) -> (sqrtf x) but does not apply the same optimization to llvm.sqrt. This is a problem because, to enable vectorization, Clang generates llvm.sqrt instead of sqrt in fast-math mode, and because this optimization is being applied to sqrt and not applied to llvm.sqrt, sometimes the fast-math code is slower. This change makes InstCombine apply this optimization to llvm.sqrt as well. This fixes the specific problem in PR17758, although the same underlying issue (optimizations applied to libcalls are not applied to intrinsics) exists for other optimizations in SimplifyLibCalls. llvm-svn: 194935
* Add instcombine visitor for addrspacecastMatt Arsenault2013-11-151-0/+4
| | | | llvm-svn: 194786
* Pull fptrunc's upwards through selects when one of the select's selectands ↵Owen Anderson2013-10-031-0/+13
| | | | | | was a constant. This has a number of benefits, including producing small immediates (easier to materialize, smaller constant pools) as well as being more likely to allow the fptrunc to fuse with a preceding instruction (truncating selects are unusual). llvm-svn: 191929
* Teach InstCombine about address spacesMatt Arsenault2013-08-211-17/+28
| | | | llvm-svn: 188926
* Teach InstCombine visitGetElementPtr about address spacesMatt Arsenault2013-08-191-2/+3
| | | | llvm-svn: 188721
* commonPointerCast cleanups to make address space change easierMatt Arsenault2013-08-191-5/+11
| | | | llvm-svn: 188719
* Use type helper functions instead of castMatt Arsenault2013-08-141-5/+3
| | | | llvm-svn: 188338
* Fix big-endian handling of integer-to-vector bitcasts in InstCombineRichard Sandiford2013-08-121-20/+32
| | | | | | | | | | These functions used to assume that the lsb of an integer corresponds to vector element 0, whereas for big-endian it's the other way around: the msb is in the first element and the lsb is in the last element. Fixes MultiSource/Benchmarks/mediabench/gsm/toast for z. llvm-svn: 188155
* InstCombine: Don't claim to be able to evaluate any shl in a zexted type.Benjamin Kramer2013-05-101-1/+11
| | | | | | | | | | The shift amount may be larger than the type leading to undefined behavior. Limit the transform to constant shift amounts. While there update the bits to clear in the result which may enable additional optimizations. PR15959. llvm-svn: 181604
* Make InstCombineCasts.cpp:OptimizeIntToFloatBitCast endian safe.Ulrich Weigand2013-03-261-1/+9
| | | | | | | | | | | | | The OptimizeIntToFloatBitCast converts shift-truncate sequences into extractelement operations. The computation of the element index to be used in the resulting operation is currently only correct for little-endian targets. This commit fixes the element index computation to be correct for big-endian targets as well. If the target byte order is unknown, the optimization cannot be performed at all. llvm-svn: 178031
* InstCombine: Don't shrink allocas when combining with a bitcast.Jim Grosbach2013-03-061-0/+6
| | | | | | | | | | When considering folding a bitcast of an alloca into the alloca itself, make sure we don't shrink the amount of memory being allocated, or things rapidly go sideways. rdar://13324424 llvm-svn: 176547
* Fix commentArnaud A. de Grandmaison2013-02-131-2/+2
| | | | | | visitSExt is an adapted copy of the related visitZExt method, so adapt the comment accordingly. llvm-svn: 175019
* Optimization: bitcast (<1 x ...> insertelement ..., X, ...) to ... ==> ↵Michael Ilseman2013-02-111-5/+16
| | | | | | bitcast X to ... llvm-svn: 174905
* InstCombine: Fix and simplify the inttoptr side too.Benjamin Kramer2013-02-051-13/+8
| | | | llvm-svn: 174438
* InstCombine: Harden code to work with vectors of pointers and simplify it a bit.Benjamin Kramer2013-02-051-11/+7
| | | | | | Found by running instcombine on a fabricated test case for the constant folder. llvm-svn: 174430
* Remove trailing whitespace.Craig Topper2013-01-241-134/+134
| | | | llvm-svn: 173322
* Fix typo in comment.Nick Lewycky2013-01-141-1/+1
| | | | llvm-svn: 172460
* Teach InstCombine to hoist FABS and FNEG through FPTRUNC instructions. The ↵Owen Anderson2013-01-101-1/+27
| | | | | | application of these operations commutes with the truncation, so we should prefer to do them in the smallest size we can, to save register space, use smaller constant pool entries, etc. llvm-svn: 172117
* Move all of the header files which are involved in modelling the LLVM IRChandler Carruth2013-01-021-1/+1
| | | | | | | | | | | | | | | | | | | | | 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
* convert a bunch of callers from DataLayout::getIndexedOffset() to ↵Nuno Lopes2012-12-301-5/+3
| | | | | | | | | GEP::accumulateConstantOffset(). The later API is nicer than the former, and is correct regarding wrap-around offsets (if anyone cares). There are a few more places left with duplicated code, which I'll remove soon. llvm-svn: 171259
OpenPOWER on IntegriCloud