summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/InstCombine/InstCombineCalls.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Assert that ValueHandleBase::ValueIsRAUWd doesn't change the tracked Value type.Frederic Riss2014-10-231-3/+9
| | | | | | | | | | | This invariant is enforced in Value::replaceAllUsesWith, thus it seems logical to apply it also to ValueHandles. This commit fixes InstCombine to not trigger the assertion during the removal of constant bitcasts in call instructions. Differential Revision: http://reviews.llvm.org/D5828 llvm-svn: 220468
* Add minnum / maxnum intrinsicsMatt Arsenault2014-10-211-0/+84
| | | | | | | | | | | | These are named following the IEEE-754 names for these functions, rather than the libm fmin / fmax to avoid possible ambiguities. Some languages may implement something resembling fmin / fmax which return NaN if either operand is to propagate errors. These implement the IEEE-754 semantics of returning the other operand if either is a NaN representing missing data. llvm-svn: 220341
* [InstCombine] Simplify the logic from r219067 using ValueTrackingHal Finkel2014-10-051-12/+4
| | | | | | | | | | | | Joerg suggested on IRC that I look at generalizing the logic from r219067 to handle more general redundancies (like removing an assume(x > 3) dominated by an assume(x > 5)). The way to do this would be to ask ValueTracking to determine the value of the i1 argument. It turns out that ValueTracking is not very good at this right now (although it does get the trivial redundancy case) because it does not understand ICmps. Nevertheless, the resulting code in InstCombine is simpler than r219067, so we might as well do it now. llvm-svn: 219070
* [InstCombine] Remove redundant @llvm.assume intrinsicsHal Finkel2014-10-041-0/+17
| | | | | | | | | For any @llvm.assume intrinsic, if there is another which dominates it and uses the same condition, then it is redundant and can be removed. While this does not alter the semantics of the @llvm.assume intrinsics, it makes subsequent handling more efficient (and the resulting IR easier to read). llvm-svn: 219067
* Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)Hal Finkel2014-09-071-14/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Add an Assumption-Tracking PassHal Finkel2014-09-071-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | This adds an immutable pass, AssumptionTracker, which keeps a cache of @llvm.assume call instructions within a module. It uses callback value handles to keep stale functions and intrinsics out of the map, and it relies on any code that creates new @llvm.assume calls to notify it of the new instructions. The benefit is that code needing to find @llvm.assume intrinsics can do so directly, without scanning the function, thus allowing the cost of @llvm.assume handling to be negligible when none are present. The current design is intended to be lightweight. We don't keep track of anything until we need a list of assumptions in some function. The first time this happens, we scan the function. After that, we add/remove @llvm.assume calls from the cache in response to registration calls and ValueHandle callbacks. There are no new direct test cases for this pass, but because it calls it validation function upon module finalization, we'll pick up detectable inconsistencies from the other tests that touch @llvm.assume calls. This pass will be used by follow-up commits that make use of @llvm.assume. llvm-svn: 217334
* Simplify creation of a bunch of ArrayRefs by using None, makeArrayRef or ↵Craig Topper2014-08-271-1/+1
| | | | | | just letting them be implicitly created. llvm-svn: 216525
* Canonicalization for @llvm.assumeHal Finkel2014-07-251-0/+17
| | | | | | | | | Adds simple logical canonicalization of assumption intrinsics to instcombine, currently: - invariant(a && b) -> invariant(a); invariant(b) - invariant(!(a || b)) -> invariant(!a); invariant(!b) llvm-svn: 213977
* InstCombine: Strength reduce sadd.with.overflow into a regular nsw add if we ↵Benjamin Kramer2014-07-041-0/+15
| | | | | | | | can prove that it cannot overflow. PR20194 llvm-svn: 212331
* R600/SI: Add intrinsics for various math instructions.Matt Arsenault2014-06-191-0/+14
| | | | | | | | These will be used for custom lowering and for library implementations of various math functions, so it's useful to expose these as builtins. llvm-svn: 211247
* [PPC64LE] Correct vperm -> shuffle transform for little endianBill Schmidt2014-06-051-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | As discussed in cfe commit r210279, the correct little-endian semantics for the vec_perm Altivec interfaces are implemented by reversing the order of the input vectors and complementing the permute control vector. This converts the desired permute from little endian element order into the big endian element order that the underlying PowerPC vperm instruction uses. This is represented with a ppc_altivec_vperm intrinsic function. The instruction combining pass contains code to convert a ppc_altivec_vperm intrinsic into a vector shuffle operation when the intrinsic has a permute control vector (mask) that is a constant. However, the vector shuffle operation assumes that vector elements are in natural order for their endianness, so for little endian code we will get the wrong result with the existing transformation. This patch reverses the semantic change to vec_perm that was performed in altivec.h by once again swapping the input operands and complementing the permute control vector, returning the element ordering to little endian. The correctness of this code is tested by the new perm.c test added in a previous patch, and by other tests in the test suite that fail without this patch. llvm-svn: 210282
* Post-commit fixes for r209643Filipe Cabecinhas2014-05-271-3/+7
| | | | | | | | | | Detected by Daniel Jasper, Ilia Filippov, and Andrea Di Biagio Fixed the argument order to select (the mask semantics to blendv* are the inverse of select) and fixed the tests Added parenthesis to the assert condition Ran clang-format llvm-svn: 209667
* Fix bad assert.Daniel Jasper2014-05-271-1/+2
| | | | llvm-svn: 209648
* Convert some X86 blendv* intrinsics into IR.Filipe Cabecinhas2014-05-271-0/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Implemented an InstCombine transformation that takes a blendv* intrinsic call and translates it into an IR select, if the mask is constant. This will eventually get lowered into blends with immediates if possible, or pblendvb (with an option to further optimize if we can transform the pblendvb into a blend+immediate instruction, depending on the selector). It will also enable optimizations by the IR passes, which give up on sight of the intrinsic. Both the transformation and the lowering of its result to asm got shiny new tests. The transformation is a bit convoluted because of blendvp[sd]'s definition: Its mask is a floating point value! This forces us to convert it and get the highest bit. I suppose this happened because the mask has type __m128 in Intel's intrinsic and v4sf (for blendps) in gcc's builtin. I will send an email to llvm-dev to discuss if we want to change this or not. Reviewers: grosbach, delena, nadav Differential Revision: http://reviews.llvm.org/D3859 llvm-svn: 209643
* AArch64/ARM64: move ARM64 into AArch64's placeTim Northover2014-05-241-3/+3
| | | | | | | | | | | | | | | This commit starts with a "git mv ARM64 AArch64" and continues out from there, renaming the C++ classes, intrinsics, and other target-local objects for consistency. "ARM64" test directories are also moved, and tests that began their life in ARM64 use an arm64 triple, those from AArch64 use an aarch64 triple. Both should be equivalent though. This finishes the AArch64 merge, and everyone should feel free to continue committing as normal now. llvm-svn: 209577
* Rename ComputeMaskedBits to computeKnownBits. "Masked" has beenJay Foad2014-05-141-6/+6
| | | | | | inappropriate since it lost its Mask parameter in r154011. llvm-svn: 208811
* Also handle ConstantAggregateZero when optimizing vpermilvar*.Rafael Espindola2014-04-291-20/+22
| | | | llvm-svn: 207582
* Remove tabs.Rafael Espindola2014-04-291-4/+4
| | | | | | Sorry, new machine and I forgot to change the editor setting. llvm-svn: 207578
* Two fixes to the vpermilvar optimization.Rafael Espindola2014-04-291-1/+24
| | | | | | | | The instcomine logic to handle vpermilvar's pd and 256 variants was incorrect. The _256 variants have indexes into the individual 128 bit lanes and in all cases it also has to mask out unused bits. llvm-svn: 207577
* [InstCombine][X86] Teach how to fold calls to SSE2/AVX2 packed logical shiftAndrea Di Biagio2014-04-261-9/+41
| | | | | | | | | | right intrinsics. A packed logical shift right with a shift count bigger than or equal to the element size always produces a zero vector. In all other cases, it can be safely replaced by a 'lshr' instruction. llvm-svn: 207299
* [C++] Use 'nullptr'. Transforms edition.Craig Topper2014-04-251-33/+32
| | | | llvm-svn: 207196
* [InstCombine][x86] Constant fold psll intrinsics.Michael J. Spencer2014-04-241-0/+41
| | | | | | | | | | | | This excludes avx512 as I don't have hardware to verify. It excludes _dq variants because they are represented in the IR as <{2,4} x i64> when it's actually a byte shift of the entire i{128,265}. This also excludes _dq_bs as they aren't at all supported by the backend. There are also no corresponding instructions in the ISA. I have no idea why they exist... llvm-svn: 207058
* Optimize some special cases for SSE4a insertqiFilipe Cabecinhas2014-04-241-0/+67
| | | | | | | | | | | | | | | | | | | | Summary: Since the upper 64 bits of the destination register are undefined when performing this operation, we can substitute it and let the optimizer figure out that only a copy is needed. Also added range merging, if an instruction copies a range that can be merged with a previous copied range. Added test cases for both optimizations. Reviewers: grosbach, nadav CC: llvm-commits Differential Revision: http://reviews.llvm.org/D3357 llvm-svn: 207055
* [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
* Simplify a vpermil* with constant mask.Rafael Espindola2014-04-211-0/+15
| | | | | | | | With a constant mask a vpermil* is just a shufflevector. This patch implements that simplification. This allows us to produce denser code. It should also allow more folding down the line. llvm-svn: 206801
* [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
* ARM64: initial backend importTim Northover2014-03-291-2/+5
| | | | | | | | | | | | This adds a second implementation of the AArch64 architecture to LLVM, accessible in parallel via the "arm64" triple. The plan over the coming weeks & months is to merge the two into a single backend, during which time thorough code review should naturally occur. Everything will be easier with the target in-tree though, hence this commit. llvm-svn: 205090
* [C++11] Add range based accessors for the Use-Def chain of a Value.Chandler Carruth2014-03-091-7/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [Modules] Move CallSite into the IR library where it belogs. It isChandler Carruth2014-03-041-1/+1
| | | | | | | abstracting between a CallInst and an InvokeInst, both of which are IR concepts. llvm-svn: 202816
* Rename many DataLayout variables from TD to DL.Rafael Espindola2014-02-211-17/+17
| | | | | | | | | 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
* Make sure that value handle users see the transformation of an indirect call ↵Nick Lewycky2014-02-201-0/+2
| | | | | | to a direct call. This is important for the CallGraph iteration. Patch by Björn Steinbrink! llvm-svn: 201822
* InstCombine: Replace custom constant folding code with ConstantExpr.Benjamin Kramer2014-02-131-26/+11
| | | | llvm-svn: 201352
* Update optimization passes to handle inalloca argumentsReid Kleckner2014-01-281-2/+5
| | | | | | | | | | | | | | | Summary: I searched Transforms/ and Analysis/ for 'ByVal' and updated those call sites to check for inalloca if appropriate. I added tests for any change that would allow an optimization to fire on inalloca. Reviewers: nlewycky Differential Revision: http://llvm-reviews.chandlerc.com/D2449 llvm-svn: 200281
* 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
* Don't refuse to transform constexpr(call(arg, ...)) to call(constexpr(arg), ↵Nick Lewycky2014-01-181-3/+4
| | | | | | ...)) just because the function has multiple return values even if their return types are the same. Patch by Eduard Burtescu! llvm-svn: 199564
* Use type helper functionsMatt Arsenault2013-09-271-1/+1
| | | | llvm-svn: 191574
* Cleanup handling of constant function casts.Matt Arsenault2013-09-171-24/+8
| | | | | | | | | | Some of this code is no longer necessary since int<->ptr casts are no longer occur as of r187444. This also fixes handling vectors of pointers, and adds a bunch of new testcases for vectors and address spaces. llvm-svn: 190885
* Change behavior of calling bitcasted alias functions.Matt Arsenault2013-07-301-9/+9
| | | | | | | | It will now only convert the arguments / return value and call the underlying function if the types are able to be bitcasted. This avoids using fp<->int conversions that would occur before. llvm-svn: 187444
* Fix using arg_end() - arg_begin() instead of arg_size()Matt Arsenault2013-06-281-3/+3
| | | | llvm-svn: 185121
* Tidy up a bit. No functional change.Jim Grosbach2013-04-051-1/+2
| | | | llvm-svn: 178915
* Revert "Have InstCombine call SipmlifyCall when handling calls. Test case ↵Andrew Trick2013-02-081-6/+0
| | | | | | | | | | included." This reverts commit 3854a5d90fee52af1065edbed34521fff6cdc18d. This causes a clang unit test to hang: vtable-available-externally.cpp. llvm-svn: 174692
* Have InstCombine call SipmlifyCall when handling calls. Test case included.Michael Ilseman2013-02-071-0/+6
| | | | llvm-svn: 174675
* Convert typeIncompatible to return an AttributeSet.Bill Wendling2013-01-301-3/+10
| | | | | | | There are still places which treat the Attribute object as a collection of attributes. I'm systematically removing them. llvm-svn: 173990
* Use the AttributeSet instead of AttributeWithIndex.Bill Wendling2013-01-271-25/+18
| | | | | | | In the future, AttributeWithIndex won't be used anymore. Besides, it exposes the internals of the AttributeSet to outside users, which isn't goodness. llvm-svn: 173602
* Remove some introspection functions.Bill Wendling2013-01-251-6/+8
| | | | | | | | The 'getSlot' function and its ilk allow introspection into the AttributeSet class. However, that class should be opaque. Allow access through accessor methods instead. llvm-svn: 173522
* Use the new 'getSlotIndex' method to retrieve the attribute's slot index.Bill Wendling2013-01-251-1/+1
| | | | llvm-svn: 173499
* Remove the last of uses that use the Attribute object as a collection of ↵Bill Wendling2013-01-231-13/+21
| | | | | | | | | attributes. Collections of attributes are handled via the AttributeSet class now. This finally frees us up to make significant changes to how attributes are structured. llvm-svn: 173228
* Have AttributeSet::getRetAttributes() return an AttributeSet instead of ↵Bill Wendling2013-01-211-4/+4
| | | | | | | | | Attribute. This further restricts the use of the Attribute class to the Attribute family of classes. llvm-svn: 173098
* Make AttributeSet::getFnAttributes() return an AttributeSet instead of an ↵Bill Wendling2013-01-211-6/+7
| | | | | | | | | Attribute. This is more code to isolate the use of the Attribute class to that of just holding one attribute instead of a collection of attributes. llvm-svn: 173094
OpenPOWER on IntegriCloud