summaryrefslogtreecommitdiffstats
path: root/llvm/test/Transforms/InstCombine/trunc.ll
Commit message (Collapse)AuthorAgeFilesLines
* [InstCombine] add test for possible cast-of-select transform; NFCSanjay Patel2020-01-141-0/+18
|
* [InstCombine] canShiftBinOpWithConstantRHS(): drop bogus signbit checkRoman Lebedev2019-05-171-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In D61918 i was looking at dropping it in DAGCombiner `visitShiftByConstant()`, but as @craig.topper pointed out, it was copied from here. That check claims that the transform is illegal otherwise. That isn't true: 1. For `ISD::ADD`, we only process `ISD::SHL` outer shift => sign bit does not matter https://rise4fun.com/Alive/K4A 2. For `ISD::AND`, there is no restriction on constants: https://rise4fun.com/Alive/Wy3 3. For `ISD::OR`, there is no restriction on constants: https://rise4fun.com/Alive/GOH 3. For `ISD::XOR`, there is no restriction on constants: https://rise4fun.com/Alive/ml6 So, why is it there then? As far as i can tell, it dates all the way back to original check-in rL7793. I think we should just drop it. Reviewers: spatel, craig.topper, efriedma, majnemer Reviewed By: spatel Subscribers: llvm-commits, craig.topper Tags: #llvm Differential Revision: https://reviews.llvm.org/D61938 llvm-svn: 361043
* [NFC][InstCombine] Regenerate trunc.ll testRoman Lebedev2019-05-151-55/+57
| | | | llvm-svn: 360759
* Revert "Temporarily Revert "Add basic loop fusion pass.""Eric Christopher2019-04-171-0/+626
| | | | | | | | The reversion apparently deleted the test/Transforms directory. Will be re-reverting again. llvm-svn: 358552
* Temporarily Revert "Add basic loop fusion pass."Eric Christopher2019-04-171-626/+0
| | | | | | | | As it's causing some bot failures (and per request from kbarton). This reverts commit r358543/ab70da07286e618016e78247e4a24fcb84077fda. llvm-svn: 358546
* [InstCombine] Consider more cases where SimplifyDemandedUseBits does not ↵Amjad Aboud2017-08-251-0/+17
| | | | | | | | | | convert AShr to LShr. There are cases where AShr have better chance to be optimized than LShr, especially when the demanded bits are not known to be Zero, and also known to be similar to the sign bit. Differential Revision: https://reviews.llvm.org/D36936 llvm-svn: 311773
* [InstCombine] Teach ComputeNumSignBitsImpl to handle integer multiply ↵Amjad Aboud2017-08-181-0/+15
| | | | | | | | instruction. Differential Revision: https://reviews.llvm.org/D36679 llvm-svn: 311206
* [InstCombine] Teach canEvaluateTruncated to handle arithmetic shift ↵Amjad Aboud2017-08-161-0/+26
| | | | | | | | (including those with vector splat shift amount) Differential Revision: https://reviews.llvm.org/D36784 llvm-svn: 311050
* [InstCombine] narrow truncated add/sub/mul with constantSanjay Patel2017-08-041-4/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Name: narrow_sub %sub = sub i32 C1, %x %r = trunc i32 %sub to i8 => %xn = trunc i32 %x to i8 %narrowC = trunc i32 C1 to i8 %r = sub i8 %narrowC, %xn Name: narrow_add %add = add i32 %x, C1 %r = trunc i32 %add to i8 => %xn = trunc i32 %x to i8 %narrowC = trunc i32 C1 to i8 %r = add i8 %xn, %narrowC Name: narrow_mul %mul = mul i32 %x, C1 %r = trunc i32 %mul to i8 => %xn = trunc i32 %x to i8 %narrowC = trunc i32 C1 to i8 %r = mul i8 %xn, %narrowC http://rise4fun.com/Alive/QpS This doesn't solve PR34046 (failure to recognize rotate): https://bugs.llvm.org/show_bug.cgi?id=34046 ...but it reduces an extra complication in the description examples to a form that we can more easily match. llvm-svn: 310141
* [InstCombine] add vector tests for truncated math; NFCSanjay Patel2017-08-041-0/+22
| | | | llvm-svn: 310122
* [InstCombine] narrow lshr with constantSanjay Patel2017-08-041-3/+3
| | | | | | | | | | | | | | | | | | | Name: narrow_shift Pre: C1 < 8 %zx = zext i8 %x to i32 %l = lshr i32 %zx, C1 => %narrowC = trunc i32 C1 to i8 %ns = lshr i8 %x, %narrowC %l = zext i8 %ns to i32 http://rise4fun.com/Alive/jIV This isn't directly applicable to PR34046 as written, but we need to have more narrowing folds like this to be sure that rotate patterns are recognized. llvm-svn: 310060
* [InstCombine] fix auto-generated FileCheck-captured variable refsSanjay Patel2017-05-101-1/+1
| | | | | | | The script at utils/update_test_checks.py has (had?) a bug when variables start with the same sequence of letters (clearly, not all of the time). llvm-svn: 302674
* [InstCombine] avoid crashing on shuffle shrinkage when input type is not ↵Sanjay Patel2017-03-081-0/+13
| | | | | | same as result type llvm-svn: 297280
* [InstCombine] shrink truncated splat shuffle (2nd try)Sanjay Patel2017-03-071-6/+4
| | | | | | | | | | | | | | | | This was committed at r297155 and reverted at r297166 because of an over-reaching clang test. That should be fixed with r297189. This is one part of solving a recent bug report: http://lists.llvm.org/pipermail/llvm-dev/2017-February/110293.html This keeps with our general approach: changing arbitrary shuffles is off-limts, but changing splat is ok. The transform is very similar to the existing shrinkBitwiseLogic() canonicalization. Differential Revision: https://reviews.llvm.org/D30123 llvm-svn: 297232
* revert r297155 because there's a clang test that depends on InstCombine:Sanjay Patel2017-03-071-4/+6
| | | | | | tools/clang/test/CodeGen/zvector.c llvm-svn: 297166
* [InstCombine] shrink truncated splat shuffleSanjay Patel2017-03-071-6/+4
| | | | | | | | | | | | | This is one part of solving a recent bug report: http://lists.llvm.org/pipermail/llvm-dev/2017-February/110293.html This keeps with our general approach: changing arbitrary shuffles is off-limts, but changing splat is ok. The transform is very similar to the existing shrinkBitwiseLogic() canonicalization. Differential Revision: https://reviews.llvm.org/D30123 llvm-svn: 297155
* [InstCombine] update trunc(shuffle) tests to reflect IR reality; NFCSanjay Patel2017-02-181-9/+40
| | | | | | | | We're ok shrinking splats, but not shuffles in general. See https://reviews.llvm.org/D30123 for discussion. llvm-svn: 295547
* [InstCombine] add tests for trunc(shuffle X, C, M); NFCSanjay Patel2017-02-171-2/+29
| | | | llvm-svn: 295513
* [InstCombine] allow vector types for constant folding / computeKnownBits ↵Sanjay Patel2016-09-161-6/+2
| | | | | | | | | | | | | | | | (PR24942) computeKnownBits() already works for integer vectors, so allow vector types when calling that from InstCombine. I don't think the change to use m_APInt in computeKnownBits is strictly necessary because we do check for ConstantVector later, but it's more efficient to handle the splat case without needing to loop on vector elements. This should work with InstSimplify, but doesn't yet, so I made that a FIXME comment on the test for PR24942: https://llvm.org/bugs/show_bug.cgi?id=24942 Differential Revision: https://reviews.llvm.org/D24677 llvm-svn: 281777
* auto-generate checksSanjay Patel2016-09-161-137/+203
| | | | llvm-svn: 281755
* Reapply "InstCombine: Reduce trunc (shl x, K) width."Matt Arsenault2016-09-131-20/+241
| | | | | | | This reapplies r272987 with a fix for infinitely looping when the truncated value is another shift of a constant. llvm-svn: 281379
* Revert "InstCombine rule to fold truncs whose value is available"Anna Thomas2016-07-081-130/+0
| | | | | | | This reverts commit r274853. Caused failure in ppcBE build llvm-svn: 274943
* InstCombine rule to fold truncs whose value is availableAnna Thomas2016-07-081-0/+130
| | | | | | | | | | | | | We can fold truncs whose operand feeds from a load, if the trunc value is available through a prior load/store. This change is from: http://reviews.llvm.org/D21246, which folded the trunc but missed the bitcast or ptrtoint/inttoptr required in the RAUW call, when the load type didnt match the prior load/store type. Differential Revision: http://reviews.llvm.org/D21791 llvm-svn: 274853
* Revert "InstCombine rule to fold trunc when value available"Reid Kleckner2016-06-241-57/+0
| | | | | | | | | | | | This reverts commit r273608. Broke building code with sanitizers, where apparently these kinds of loads, casts, and truncations are common: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/24502 http://crbug.com/623099 llvm-svn: 273703
* InstCombine rule to fold trunc when value availableAnna Thomas2016-06-231-0/+57
| | | | | | | | | | | | | | Summary: This instcombine rule folds away trunc operations that have value available from a prior load or store. This kind of code can be generated as a result of GVN widening the load or from source code as well. Reviewers: reames, majnemer, sanjoy Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D21246 llvm-svn: 273608
* Add looping testcase that broke in r272987Matt Arsenault2016-06-181-0/+21
| | | | llvm-svn: 273081
* Revert "Revert "Revert "InstCombine: Reduce trunc (shl x, K) width."""Matt Arsenault2016-06-171-135/+0
| | | | | | | This seems to be causing an infinite loop / crash in instcombine on some bots. llvm-svn: 273069
* Revert "Revert "InstCombine: Reduce trunc (shl x, K) width.""Matt Arsenault2016-06-171-0/+135
| | | | | | | Reapply r272987. Condition should be in terms of the destination type, and the flags should not be copied. llvm-svn: 273045
* Revert "InstCombine: Reduce trunc (shl x, K) width."Matt Arsenault2016-06-171-109/+0
| | | | | | | | This reverts commit r272987. This might be causing crashes on some bots. llvm-svn: 272990
* InstCombine: Reduce trunc (shl x, K) width.Matt Arsenault2016-06-171-0/+109
| | | | llvm-svn: 272987
* [InstCombine] fold trunc ([lshr] (bitcast vector) ) --> extractelement (PR25543)Sanjay Patel2015-12-141-11/+7
| | | | | | | | | | | | | | | | | | | | | | | This is a fix for PR25543: https://llvm.org/bugs/show_bug.cgi?id=25543 The idea is to take the existing fold of: bitcast ( trunc ( lshr ( bitcast X))) --> extractelement (bitcast X) ( http://reviews.llvm.org/rL112232 ) And break it into less specific transforms so we'll catch more cases such as the example in the bug report: bitcast ( trunc ( lshr ( bitcast X))) --> bitcast ( extractelement (bitcast X)) --> extractelement (bitcast X) Enabling patches for this change: http://reviews.llvm.org/rL255399 (combine bitcasts) http://reviews.llvm.org/rL255433 (canonicalize extractelement(bitcast X)) Differential Revision: http://reviews.llvm.org/D15392 llvm-svn: 255504
* [InstCombine] add tests to show missing trunc optimizationsSanjay Patel2015-11-191-0/+46
| | | | llvm-svn: 253609
* Update Transforms tests to use CHECK-LABEL for easier debugging. No ↵Stephen Lin2013-07-141-10/+10
| | | | | | | | | | | | | | | | | | | | | | functionality change. This update was done with the following bash script: find test/Transforms -name "*.ll" | \ while read NAME; do echo "$NAME" if ! grep -q "^; *RUN: *llc" $NAME; then TEMP=`mktemp -t temp` cp $NAME $TEMP sed -n "s/^define [^@]*@\([A-Za-z0-9_]*\)(.*$/\1/p" < $NAME | \ while read FUNC; do sed -i '' "s/;\(.*\)\([A-Za-z0-9_]*\):\( *\)@$FUNC\([( ]*\)\$/;\1\2-LABEL:\3@$FUNC(/g" $TEMP done mv $TEMP $NAME fi done llvm-svn: 186268
* Revert remaining part of r93200: "Disable folding sext(trunc(x)) -> x"Jakob Stoklund Olesen2012-06-221-6/+7
| | | | | | | | | | | This fixes PR5997. These transforms were disabled because codegen couldn't deal with other uses of trunc(x). This is now handled by the peephole pass. This causes no regressions on x86-64. llvm-svn: 159003
* Enhance a bunch of transformations in instcombine to start generatingChris Lattner2011-02-101-2/+2
| | | | | | | | | | | exact/nsw/nuw shifts and have instcombine infer them when it can prove that the relevant properties are true for a given shift without them. Also, a variety of refactoring to use the new patternmatch logic thrown in for good luck. I believe that this takes care of a bunch of related code quality issues attached to PR8862. llvm-svn: 125267
* implement an instcombine xform that canonicalizes casts outside of ↵Chris Lattner2011-01-151-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | and-with-constant operations. This fixes rdar://8808586 which observed that we used to compile: union xy { struct x { _Bool b[15]; } x; __attribute__((packed)) struct y { __attribute__((packed)) unsigned long b0to7; __attribute__((packed)) unsigned int b8to11; __attribute__((packed)) unsigned short b12to13; __attribute__((packed)) unsigned char b14; } y; }; struct x foo(union xy *xy) { return xy->x; } into: _foo: ## @foo movq (%rdi), %rax movabsq $1095216660480, %rcx ## imm = 0xFF00000000 andq %rax, %rcx movabsq $-72057594037927936, %rdx ## imm = 0xFF00000000000000 andq %rax, %rdx movzbl %al, %esi orq %rdx, %rsi movq %rax, %rdx andq $65280, %rdx ## imm = 0xFF00 orq %rsi, %rdx movq %rax, %rsi andq $16711680, %rsi ## imm = 0xFF0000 orq %rdx, %rsi movl %eax, %edx andl $-16777216, %edx ## imm = 0xFFFFFFFFFF000000 orq %rsi, %rdx orq %rcx, %rdx movabsq $280375465082880, %rcx ## imm = 0xFF0000000000 movq %rax, %rsi andq %rcx, %rsi orq %rdx, %rsi movabsq $71776119061217280, %r8 ## imm = 0xFF000000000000 andq %r8, %rax orq %rsi, %rax movzwl 12(%rdi), %edx movzbl 14(%rdi), %esi shlq $16, %rsi orl %edx, %esi movq %rsi, %r9 shlq $32, %r9 movl 8(%rdi), %edx orq %r9, %rdx andq %rdx, %rcx movzbl %sil, %esi shlq $32, %rsi orq %rcx, %rsi movl %edx, %ecx andl $-16777216, %ecx ## imm = 0xFFFFFFFFFF000000 orq %rsi, %rcx movq %rdx, %rsi andq $16711680, %rsi ## imm = 0xFF0000 orq %rcx, %rsi movq %rdx, %rcx andq $65280, %rcx ## imm = 0xFF00 orq %rsi, %rcx movzbl %dl, %esi orq %rcx, %rsi andq %r8, %rdx orq %rsi, %rdx ret We now compile this into: _foo: ## @foo ## BB#0: ## %entry movzwl 12(%rdi), %eax movzbl 14(%rdi), %ecx shlq $16, %rcx orl %eax, %ecx shlq $32, %rcx movl 8(%rdi), %edx orq %rcx, %rdx movq (%rdi), %rax ret A small improvement :-) llvm-svn: 123520
* teach the truncation optimization that an entire chain ofChris Lattner2010-08-271-4/+21
| | | | | | | computation can be truncated if it is fed by a sext/zext that doesn't have to be exactly equal to the truncation result type. llvm-svn: 112285
* Add an instcombine to clean up a common pattern producedChris Lattner2010-08-271-0/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | by the SRoA "promote to large integer" code, eliminating some type conversions like this: %94 = zext i16 %93 to i32 ; <i32> [#uses=2] %96 = lshr i32 %94, 8 ; <i32> [#uses=1] %101 = trunc i32 %96 to i8 ; <i8> [#uses=1] This also unblocks other xforms from happening, now clang is able to compile: struct S { float A, B, C, D; }; float foo(struct S A) { return A.A + A.B+A.C+A.D; } into: _foo: ## @foo ## BB#0: ## %entry pshufd $1, %xmm0, %xmm2 addss %xmm0, %xmm2 movdqa %xmm1, %xmm3 addss %xmm2, %xmm3 pshufd $1, %xmm1, %xmm0 addss %xmm3, %xmm0 ret on x86-64, instead of: _foo: ## @foo ## BB#0: ## %entry movd %xmm0, %rax shrq $32, %rax movd %eax, %xmm2 addss %xmm0, %xmm2 movapd %xmm1, %xmm3 addss %xmm2, %xmm3 movd %xmm1, %rax shrq $32, %rax movd %eax, %xmm0 addss %xmm3, %xmm0 ret This seems pretty close to optimal to me, at least without using horizontal adds. This also triggers in lots of other code, including SPEC. llvm-svn: 112278
* filecheckizeChris Lattner2010-08-261-7/+19
| | | | llvm-svn: 112235
* rename test.Chris Lattner2010-08-261-0/+38
llvm-svn: 112234
OpenPOWER on IntegriCloud