summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/InstCombine/InstCombineInternal.h
Commit message (Collapse)AuthorAgeFilesLines
...
* [InstCombine] allow non-splat folds of select cond (ext X), CSanjay Patel2016-09-301-2/+1
| | | | llvm-svn: 282906
* [InstCombine] fix function names; NFCSanjay Patel2016-09-291-6/+10
| | | | | | | | Also, make foldSelectExtConst() a member of InstCombiner, remove unnecessary parameters from its interface, and group visitSelectInst helpers together in the header file. llvm-svn: 282796
* [InstCombine] add helper functions for visitICmpInst(); NFCISanjay Patel2016-09-161-0/+3
| | | | llvm-svn: 281743
* [InstCombine] move folds for icmp (sh C2, Y), C1 in with other icmp+sh ↵Sanjay Patel2016-09-151-4/+4
| | | | | | folds; NFCI llvm-svn: 281672
* [InstCombine] allow icmp (shr/shl) folds for vectorsSanjay Patel2016-09-151-2/+2
| | | | | | | | | | | | These 2 helper functions were already using APInt internally, so just change the API and caller to allow folds for splats. The scalar regression tests look quite thorough, so I just added a couple of tests to prove that vectors are handled too. These folds should be grouped with the other cmp+shift folds though. That can be an NFC follow-up. llvm-svn: 281663
* [InstCombine] add helper function for foldICmpWithConstant; NFCSanjay Patel2016-09-151-0/+1
| | | | | | | This is a big glob of transforms that probably should work for vectors, but currently they are disallowed because of ConstantInt guards. llvm-svn: 281614
* [InstCombine] add helper function for foldICmpUsingKnownBits; NFCISanjay Patel2016-09-121-0/+1
| | | | llvm-svn: 281217
* fix formatting/typos; NFCSanjay Patel2016-09-121-5/+5
| | | | llvm-svn: 281214
* [InstCombine] rename and reorganize some icmp folding functions; NFCSanjay Patel2016-09-101-3/+6
| | | | | | | | | | Everything under foldICmpInstWithConstant() should now be working for splat vectors via m_APInt matchers. Ie, I've removed all of the FIXMEs that I added while cleaning that section up. Note that not all of the associated FIXMEs in the regression tests are gone though, because some of the tests require earlier folds that are still scalar-only. llvm-svn: 281139
* [InstCombine] use m_APInt to allow icmp (and (sh X, Y), C2), C1 folds for ↵Sanjay Patel2016-09-071-1/+1
| | | | | | splat constant vectors llvm-svn: 280873
* [InstCombine] change insertRangeTest() to use APInt instead of Constant; NFCISanjay Patel2016-08-311-2/+2
| | | | | | | | This is prep work before changing the callers to also use APInt which will allow folds for splat vectors. Currently, the callers have ConstantInt guards in place, so no functional change intended with this commit. llvm-svn: 280282
* [InstCombine] add helper function for icmp (and (sh X, Y), C2), C1 ; NFCSanjay Patel2016-08-261-1/+3
| | | | | | | | Like other recent changes near here, the goal is to allow vector types for all of these folds. Splitting things up makes it easier to incrementally enhance the code and easier to read. llvm-svn: 279851
* [InstCombine] add helper function for folding of icmp (and X, C2), C; NFCSanjay Patel2016-08-261-0/+2
| | | | llvm-svn: 279834
* [InstCombine] move foldICmpDivConstConst() contents to ↵Sanjay Patel2016-08-241-2/+0
| | | | | | | | | foldICmpDivConstant(); NFCI There was no logic in foldICmpDivConstant, so no need for a separate function. The code is directly copy/pasted, so further cleanups to follow. llvm-svn: 279685
* [InstCombine] move foldICmpShrConstConst() contents to foldICmpShrConst(); NFCISanjay Patel2016-08-231-2/+0
| | | | | | | There will only be 3 lines of code in foldICmpShrConst() when the cleanup is done, so it doesn't make much sense to have a separate function for a single fold. llvm-svn: 279575
* [InstCombine] change param type from Instruction to BinaryOperator for icmp ↵Sanjay Patel2016-08-221-24/+24
| | | | | | | | helpers; NFCI This saves some casting in the helper functions and eases some further refactoring. llvm-svn: 279478
* [InstCombine] add helper functions for foldICmpWithConstant; NFCISanjay Patel2016-08-161-4/+28
| | | | | | | | | | | | | Besides breaking up a 700 line function to improve readability, this sinks the 'FIXME: ConstantInt' check into each helper. So now we can independently break that restriction within any of the helper functions. As much as possible, the code was only {cut/paste/clang-format}'ed to minimize risk (no functional changes intended), so several more readability improvements are still possible. llvm-svn: 278828
* [InstCombine] use m_APInt in foldICmpWithConstant; NFCISanjay Patel2016-08-161-2/+1
| | | | | | | | | | | There's some formatting and pointer deref ugliness here that I intend to fix in subsequent patches. The overall goal is to refactor the obnoxiously long switch and incrementally remove the restriction to scalar types (allow folds for vector splats). This patch introduces the use of m_APInt which means the RHSV reference is now a pointer (and may have matched a vector splat), but the check of 'RHS' remains, so vector folds are disallowed and no functional change is intended. llvm-svn: 278816
* constify InstCombine::foldAllocaCmp. NFC.Pete Cooper2016-08-121-1/+2
| | | | | | | | This is part of an effort to constify ValueTracking.cpp. This change is to methods which need const Value* instead of Value* to go with the upcoming changes to ValueTracking. llvm-svn: 278528
* InstCombine: Replace some never-null pointers with references. NFCJustin Bogner2016-08-051-17/+16
| | | | llvm-svn: 277792
* IR: Provide an IRBuilder Inserter that calls a callback after insertionJustin Bogner2016-08-041-23/+1
| | | | | | | | | | Add a generalized IRBuilderCallbackInserter, which is just given a callback to execute after insertion. This can be used to get rid of the custom inserter in InstCombine, which will in turn allow me to add target specific InstCombineCalls API for intrinsics without horrible layering violations. llvm-svn: 277784
* [InstCombine] replace dyn_casts with matches; NFCISanjay Patel2016-08-021-2/+1
| | | | | | Clean-up before changing this to allow folds for vectors. llvm-svn: 277538
* [InstCombine] allow icmp (bit-manipulation-intrinsic(), C) folds for vectorsSanjay Patel2016-07-231-2/+1
| | | | llvm-svn: 276523
* [InstCombine] break up foldICmpEqualityWithConstant(); NFCISanjay Patel2016-07-211-0/+2
| | | | | | | Almost all of these folds require changes to allow vector types. Splitting up the logic should make that easier to do incrementally. llvm-svn: 276360
* make InstCombine compare helper functions private; NFCSanjay Patel2016-07-211-23/+24
| | | | | | Also, rename some of them for consistency and to follow current conventions. llvm-svn: 276312
* [InstCombine] break up visitICmpInstWithInstAndIntCst(); NFCISanjay Patel2016-07-211-0/+2
| | | | | | | Making smaller pieces out of some of these ~1000 line functions should make it easier to incrementally upgrade them to handle vector types. llvm-svn: 276304
* [InstCombine] Minor cleanup of cast simplification code [NFC]Tobias Grosser2016-07-191-9/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch cleans up parts of InstCombine to raise its compliance with the LLVM coding standards and to increase its readability. The changes and according rationale are summarized in the following: - Rename `ShouldOptimizeCast()` to `shouldOptimizeCast()` since functions should start with a lower case letter. - Move `shouldOptimizeCast()` from InstCombineCasts.cpp to InstCombineAndOrXor.cpp since it's only used there. - Simplify interface of `shouldOptimizeCast()`. - Minor code style adaptions in `shouldOptimizeCast()`. - Remove the documentation on the function definition of `shouldOptimizeCast()` since it just repeats the documentation on its declaration. Also enhance the documentation on its declaration with more information describing its intended use and make it doxygen-compliant. - Change a comment in `foldCastedBitwiseLogic()` from `fold (logic (cast A), (cast B)) -> (cast (logic A, B))` to `fold logic(cast(A), cast(B)) -> cast(logic(A, B))` since the surrounding comments use this format. - Remove comment `Only do this if the casts both really cause code to be generated.` in `foldCastedBitwiseLogic()` since it just repeats parts of the documentation of `shouldOptimizeCast()` and does not help to improve readability. - Simplify the interface of `isEliminableCastPair()`. - Removed the documentation on the function definition of `isEliminableCastPair()` which only contained obvious statements about its implementation. Instead added more general doxygen-compliant documentation to its declaration. - Renamed parameter `DoXform` of `transformZExtIcmp()` to `DoTransform` to make its intention clearer. - Moved documentation of `transformZExtIcmp()` from its definition to its declaration and made it doxygen-compliant. Reviewers: vtjnash, grosser Subscribers: majnemer, llvm-commits Differential Revision: https://reviews.llvm.org/D22449 Contributed-by: Matthias Reisinger llvm-svn: 275964
* Revert "[InstCombine] Avoid combining the bitcast of a var that is used as ↵Eric Christopher2016-06-291-1/+0
| | | | | | | | | | | | both address and result of load instructions" Revert "[InstCombine] Combine A->B->A BitCast" as this appears to cause PR27996 and as discussed in http://reviews.llvm.org/D20847 This reverts commits r270135 and r263734. llvm-svn: 274094
* Apply most suggestions of clang-tidy's performance-unnecessary-value-paramBenjamin Kramer2016-06-081-2/+2
| | | | | | | Avoids unnecessary copies. All changes audited & pass tests with asan. No functional change intended. llvm-svn: 272190
* Clarify that we match BSwap in InstCombine and BitReverse in CGP. NFC.Chad Rosier2016-05-251-1/+1
| | | | | | | | Also, rename recognizeBitReverseOrBSwapIdiom to recognizeBSwapOrBitReverseIdiom, so the ordering of the MatchBSwaps and MatchBitReversals arguments are consistent with the function name. llvm-svn: 270715
* [InstCombine] Remove trivially empty va_start/va_end and va_copy/va_end ranges.Arnaud A. de Grandmaison2016-05-101-0/+2
| | | | | | | | | | | | When a va_start or va_copy is immediately followed by a va_end (ignoring debug information or other start/end in between), then it is safe to remove the pair. As this code shares some commonalities with the lifetime markers, this has been factored to helper functions. This InstCombine pattern kicks-in 3 times when running the LLVM test suite. llvm-svn: 269033
* [InstCombine] Combine A->B->A BitCastGuozhi Wei2016-03-171-0/+1
| | | | | | | | | | This patch enhances InstCombine to handle following case: A -> B bitcast PHI B -> A bitcast llvm-svn: 263734
* Remove PreserveNames template parameter from IRBuilderMehdi Amini2016-03-131-3/+3
| | | | | | | | This reapplies r263258, which was reverted in r263321 because of issues on Clang side. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 263393
* Temporarily revert:Eric Christopher2016-03-121-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit ae14bf6488e8441f0f6d74f00455555f6f3943ac Author: Mehdi Amini <mehdi.amini@apple.com> Date: Fri Mar 11 17:15:50 2016 +0000 Remove PreserveNames template parameter from IRBuilder Summary: Following r263086, we are now relying on a flag on the Context to discard Value names in release builds. Reviewers: chandlerc Subscribers: mzolotukhin, llvm-commits Differential Revision: http://reviews.llvm.org/D18023 From: Mehdi Amini <mehdi.amini@apple.com> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263258 91177308-0d34-0410-b5e6-96231b3b80d8 until we can figure out what to do about clang and Release build testing. This reverts commit 263258. llvm-svn: 263321
* Remove PreserveNames template parameter from IRBuilderMehdi Amini2016-03-111-3/+3
| | | | | | | | | | | | | | | Summary: Following r263086, we are now relying on a flag on the Context to discard Value names in release builds. Reviewers: chandlerc Subscribers: mzolotukhin, llvm-commits Differential Revision: http://reviews.llvm.org/D18023 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 263258
* InstCombine: Restrict computeKnownBits() on all Values to OptLevel > 2Matthias Braun2016-03-091-2/+5
| | | | | | | | | | | | | | | | | | As part of r251146 InstCombine was extended to call computeKnownBits on every value in the function to determine whether it happens to be constant. This increases typical compiletime by 1-3% (5% in irgen+opt time) in my measurements. On the other hand this case did not trigger once in the whole llvm-testsuite. This patch introduces the notion of ExpensiveCombines which are only enabled for OptLevel > 2. I removed the check in InstructionSimplify as that is called from various places where the OptLevel is not known but given the rarity of the situation I think a check in InstCombine is enough. Differential Revision: http://reviews.llvm.org/D16835 llvm-svn: 263047
* Revert "[InstCombine] Combine A->B->A BitCast"Junmo Park2016-03-081-1/+0
| | | | | | This reverts commit r262670 due to compile failure. llvm-svn: 262916
* [InstCombine] Combine A->B->A BitCastGuozhi Wei2016-03-031-0/+1
| | | | | | | | | | This patch enhances InstCombine to handle following case: A -> B bitcast PHI B -> A bitcast llvm-svn: 262670
* [InstCombine] add helper function to foldCastedBitwiseLogic() ; NFCISanjay Patel2016-02-231-0/+1
| | | | | | | | | | | | This is a straight cut and paste of the existing code and is intended to be the first step in solving part of PR26702: https://llvm.org/bugs/show_bug.cgi?id=26702 We should be able to reuse most of this and delete the nearly identical existing code in visitOr(). Then, we can enhance visitXor() to use the same code too. llvm-svn: 261649
* function names start with a lowercase letter; NFCSanjay Patel2016-02-011-2/+2
| | | | llvm-svn: 259425
* use range-based for loop; NFCSanjay Patel2016-01-311-3/+3
| | | | llvm-svn: 259325
* fix typo; NFCSanjay Patel2016-01-061-1/+1
| | | | llvm-svn: 256883
* [InstCombine] Make MatchBSwap also match bit reversalsJames Molloy2015-12-111-1/+1
| | | | | | MatchBSwap has most of the functionality to match bit reversals already. If we switch it from looking at bytes to individual bits and remove a few early exits, we can extend the main recursive function to match any sequence of ORs, ANDs and shifts that assemble a value from different parts of another, base value. Once we have this bit->bit mapping, we can very simply detect if it is appropriate for a bswap or bitreverse. llvm-svn: 255334
* Revert "Change memcpy/memset/memmove to have dest and source alignments."Pete Cooper2015-11-191-1/+1
| | | | | | | | | | This reverts commit r253511. This likely broke the bots in http://lab.llvm.org:8011/builders/clang-ppc64-elf-linux2/builds/20202 http://bb.pgr.jp/builders/clang-3stage-i686-linux/builds/3787 llvm-svn: 253543
* Change memcpy/memset/memmove to have dest and source alignments.Pete Cooper2015-11-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note, this was reviewed (and more details are in) http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312083.html These intrinsics currently have an explicit alignment argument which is required to be a constant integer. It represents the alignment of the source and dest, and so must be the minimum of those. This change allows source and dest to each have their own alignments by using the alignment attribute on their arguments. The alignment argument itself is removed. There are a few places in the code for which the code needs to be checked by an expert as to whether using only src/dest alignment is safe. For those places, they currently take the minimum of src/dest alignments which matches the current behaviour. For example, code which used to read: call void @llvm.memcpy.p0i8.p0i8.i32(i8* %dest, i8* %src, i32 500, i32 8, i1 false) will now read: call void @llvm.memcpy.p0i8.p0i8.i32(i8* align 8 %dest, i8* align 8 %src, i32 500, i1 false) For out of tree owners, I was able to strip alignment from calls using sed by replacing: (call.*llvm\.memset.*)i32\ [0-9]*\,\ i1 false\) with: $1i1 false) and similarly for memmove and memcpy. I then added back in alignment to test cases which needed it. A similar commit will be made to clang which actually has many differences in alignment as now IRBuilder can generate different source/dest alignments on calls. In IRBuilder itself, a new argument was added. Instead of calling: CreateMemCpy(Dst, Src, getInt64(Size), DstAlign, /* isVolatile */ false) you now call CreateMemCpy(Dst, Src, getInt64(Size), DstAlign, SrcAlign, /* isVolatile */ false) There is a temporary class (IntegerAlignment) which takes the source alignment and rejects implicit conversion from bool. This is to prevent isVolatile here from passing its default parameter to the source alignment. Note, changes in future can now be made to codegen. I didn't change anything here, but this change should enable better memcpy code sequences. Reviewed by Hal Finkel. llvm-svn: 253511
* 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
* InstCombine: Fold comparisons between unguessable allocas and other pointersHans Wennborg2015-10-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This will allow us to optimize code such as: int f(int *p) { int x; return p == &x; } as well as: int *allocate(void); int f() { int x; int *p = allocate(); return p == &x; } The folding can only be done under certain circumstances. Even though p and &x cannot alias, the comparison must still return true if the pointer representations are equal. If a user successfully generates a p that's a correct guess for &x, comparison should return true even though p is an invalid pointer. This patch argues that if the address of the alloca isn't observable outside the function, the function can act as-if the address is impossible to guess from the outside. The tricky part is keeping the act consistent: if we fold p == &x to false in one place, we must make sure to fold any other comparisons based on those pointers similarly. To ensure that, we only fold when &x is involved exactly once in comparison instructions. Differential Revision: http://reviews.llvm.org/D13358 llvm-svn: 249490
* [InstCombine] fold zexts and constants into a phi (PR24766)Sanjay Patel2015-09-271-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is one step towards solving PR24766: https://llvm.org/bugs/show_bug.cgi?id=24766 We were not producing the same IR for these two C functions because the store to the temp bool causes extra zexts: #include <stdbool.h> bool switchy(char x1, char x2, char condition) { bool conditionMet = false; switch (condition) { case 0: conditionMet = (x1 == x2); break; case 1: conditionMet = (x1 <= x2); break; } return conditionMet; } bool switchy2(char x1, char x2, char condition) { switch (condition) { case 0: return (x1 == x2); case 1: return (x1 <= x2); } return false; } As noted in the code comments, this test case manages to avoid the more general existing phi optimizations where there are only 2 phi inputs or where there are no constant phi args mixed in with the casts ops. It seems like a corner case, but if we don't catch it, then I don't think we can get SimplifyCFG to further optimize towards the canonical form for this function shown in the bug report. Differential Revision: http://reviews.llvm.org/D12866 llvm-svn: 248689
* add ShouldChangeType() variant that takes bitwidthsSanjay Patel2015-09-211-0/+1
| | | | | | This is more efficient for cases like D12965 where we already have widths. llvm-svn: 248170
* [InstCombine] Fix PR24605.Sanjoy Das2015-08-281-0/+5
| | | | | | | | | | | | | | PR24605 is caused due to an incorrect insert point in instcombine's IR builder. When simplifying %t = add X Y ... %m = icmp ... %t the replacement for %t should be placed before %t, not before %m, as there could be a use of %t between %t and %m. llvm-svn: 246315
OpenPOWER on IntegriCloud