summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/InstCombine
Commit message (Collapse)AuthorAgeFilesLines
...
* [InstCombine] Simplify a known nonzero incoming value of PHIJun Bum Lim2016-02-111-0/+36
| | | | | | | | | | | | | | | | | | | | Summary: When a PHI is used only to be compared with zero, it is possible to replace an incoming value with any non-zero constant if the incoming value can be proved as a known nonzero value. For example, in below code, we can replace the incoming value %v with any non-zero constant based on the fact that the PHI is only used to be compared with zero and %v is a known non-zero value: %v = select %cond, 1, 2 %p = phi [%v, BB] ... %c = icmp eq, %p, 0 Reviewers: mcrosier, jmolloy, sanjoy Subscribers: hfinkel, mcrosier, majnemer, llvm-commits, haicheng, bmakam, mssimpso, gberry Differential Revision: http://reviews.llvm.org/D16240 llvm-svn: 260530
* Don't propagate dereferenceable attribute through gc.relocate in InstCombineArtur Pilipenko2016-02-111-6/+0
| | | | | | | | Reviewed By: reames Differential Revision: http://reviews.llvm.org/D16143 llvm-svn: 260509
* [InstCombine][GC] Handle gc.relocations of vector typePhilip Reames2016-02-091-25/+22
| | | | | | | | We introduced gc.relocates of vector-of-pointer types a couple of weeks back. Somehow, I missed updating the InstCombine rule to account for this. If we hit this code path with a vector-of-pointers gc.relocate, we'd crash on a cast<PointerType>. I also took the chance to do a bit of code style cleanup. llvm-svn: 260279
* [InstCombine] Revert r238452: Fold IntToPtr and PtrToInt into preceding loads.Quentin Colombet2016-02-031-10/+5
| | | | | | | | | | | | | | | | | | | | | | | | | According to git bisect, this is the root cause of a miscompile for Regex in libLLVMSupport. I am still working on reducing a test case. The actual bug may be elsewhere and this commit just exposed it. Anyway, at the moment, to reproduce, follow these steps: 1. Build clang and libLTO in release mode. 2. Create a new build directory <stage2> and cd into it. 3. Use clang and libLTO from #1 to build llvm-extract in Release mode + asserts using -O2 -flto 4. Run llvm-extract -ralias '.*bar' -S test/Other/extract-alias.ll Result: program doesn't contain global named '.*bar'! Expected result: @a0a0bar = alias void ()* @bar @a0bar = alias void ()* @bar declare void @bar() Note: In step #3, if you don't use lto or asserts, the miscompile disappears. llvm-svn: 259674
* Fix Clang-tidy readability-redundant-control-flow warnings; other minor fixes.Eugene Zelenko2016-02-021-2/+0
| | | | | | Differential revision: http://reviews.llvm.org/D16793 llvm-svn: 259539
* function names start with a lowercase letter; NFCSanjay Patel2016-02-0114-324/+324
| | | | llvm-svn: 259425
* [InstCombine] simplify masked scatter/gather intrinsics with zero masksSanjay Patel2016-02-011-4/+22
| | | | | | | | | | | A masked scatter with a zero mask means there's no store. A masked gather with a zero mask means the passthru arg is returned. This is a continuation of: http://reviews.llvm.org/rL259369 http://reviews.llvm.org/rL259392 llvm-svn: 259421
* [InstCombine] simplify masked store intrinsics with all ones or zeros masksSanjay Patel2016-02-011-1/+21
| | | | | | | | | | A masked store with a zero mask means there's no store. A masked store with an allOnes mask means it's a normal vector store. This is a continuation of: http://reviews.llvm.org/rL259369 llvm-svn: 259392
* [InstCombine] Don't transform (X+INT_MAX)>=(Y+INT_MAX) -> (X<=Y)David Majnemer2016-02-011-1/+1
| | | | | | | | | This miscompile came about because we tried to use a transform which was only appropriate for xor operators when addition was present. This fixes PR26407. llvm-svn: 259375
* [InstCombine] simplify masked load intrinsics with all ones or zeros masksSanjay Patel2016-02-011-0/+30
| | | | | | | | | A masked load with a zero mask means there's no load. A masked load with an allOnes mask means it's a normal vector load. Differential Revision: http://reviews.llvm.org/D16691 llvm-svn: 259369
* add helper function for minnum/maxnum ; NFCSanjay Patel2016-01-311-74/+80
| | | | llvm-svn: 259326
* use range-based for loop; NFCSanjay Patel2016-01-311-3/+3
| | | | llvm-svn: 259325
* fix formatting; NFCSanjay Patel2016-01-311-13/+13
| | | | llvm-svn: 259324
* simplify; NFCSanjay Patel2016-01-311-8/+5
| | | | llvm-svn: 259323
* InstCombine: fabs(x) * fabs(x) -> x * xMatt Arsenault2016-01-301-4/+15
| | | | llvm-svn: 259295
* Avoid overly large SmallPtrSet/SmallSetMatthias Braun2016-01-301-1/+1
| | | | | | | These sets perform linear searching in small mode so it is never a good idea to use SmallSize/N bigger than 32. llvm-svn: 259283
* function names start with a lower case letter ; NFCSanjay Patel2016-01-291-25/+25
| | | | llvm-svn: 259264
* fix formatting; NFCSanjay Patel2016-01-291-4/+8
| | | | llvm-svn: 259262
* [InstCombine] avoid an insertelement transformation that induces the ↵Sanjay Patel2016-01-291-1/+17
| | | | | | | | | | | opposite extractelement fold (PR26354) We would infinite loop because we created a shufflevector that was wider than needed and then failed to combine that with the insertelement. When subsequently visiting the extractelement from that shuffle, we see that it's unnecessary, delete it, and trigger another visit to the insertelement. llvm-svn: 259236
* less indenting; NFCISanjay Patel2016-01-281-107/+109
| | | | llvm-svn: 259002
* Remove autoconf supportChris Bieneman2016-01-261-15/+0
| | | | | | | | | | | | | | | | Summary: This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html "I felt a great disturbance in the [build system], as if millions of [makefiles] suddenly cried out in terror and were suddenly silenced. I fear something [amazing] has happened." - Obi Wan Kenobi Reviewers: chandlerc, grosbach, bob.wilson, tstellarAMD, echristo, whitequark Subscribers: chfast, simoncook, emaste, jholewinski, tberghammer, jfb, danalbert, srhines, arsenm, dschuff, jyknight, dsanders, joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D16471 llvm-svn: 258861
* [InstCombine, SCCP] Consolidate code used to remove instructionsDavid Majnemer2016-01-241-18/+3
| | | | | | | | | InstCombine and SCCP both want to remove dead code in a very particular way but using identical means to do so. Share the code between the two. No functionality change is intended. llvm-svn: 258653
* AMDGPU: Rename intrinsics to use amdgcn prefixMatt Arsenault2016-01-221-1/+1
| | | | | | | | | | | The intrinsic target prefix should match the target name as it appears in the triple. This is not yet complete, but gets most of the important ones. llvm.AMDGPU.* intrinsics used by mesa and libclc are still handled for compatability for now. llvm-svn: 258557
* [opaque pointer types] [NFC] FindAvailableLoadedValue: take LoadInst instead ↵Eduard Burtescu2016-01-221-1/+1
| | | | | | | | | | | | of just the pointer. Reviewers: mjacob, dblaikie Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D16422 llvm-svn: 258477
* don't repeat function names in comments; NFCSanjay Patel2016-01-201-19/+14
| | | | llvm-svn: 258360
* 80-cols; NFCSanjay Patel2016-01-201-2/+2
| | | | llvm-svn: 258323
* remove outdated comment; NFCSanjay Patel2016-01-191-4/+0
| | | | llvm-svn: 258147
* [opaque pointer types] [NFC] GEP: replace get(Pointer)ElementType uses with ↵Eduard Burtescu2016-01-192-16/+13
| | | | | | | | | | | | | | | | | | get{Source,Result}ElementType. Summary: GEPOperator: provide getResultElementType alongside getSourceElementType. This is made possible by adding a result element type field to GetElementPtrConstantExpr, which GetElementPtrInst already has. GEP: replace get(Pointer)ElementType uses with get{Source,Result}ElementType. Reviewers: mjacob, dblaikie Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D16275 llvm-svn: 258145
* combine clauses with same output ; NFCISanjay Patel2016-01-181-8/+3
| | | | llvm-svn: 258062
* use m_OneUse ; NFCISanjay Patel2016-01-181-4/+2
| | | | llvm-svn: 258059
* fix variable names, typos ; NFCSanjay Patel2016-01-181-36/+36
| | | | llvm-svn: 258058
* fix typo; NFCSanjay Patel2016-01-181-1/+1
| | | | llvm-svn: 258057
* [opaque pointer types] [breaking-change] [NFC] SimplifyGEPInst: take the ↵Manuel Jacob2016-01-171-1/+1
| | | | | | | | | | | | | | source element type of the GEP as an argument. Patch by Eduard Burtescu. Reviewers: dblaikie, mjacob Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D16281 llvm-svn: 258024
* GlobalValue: use getValueType() instead of getType()->getPointerElementType().Manuel Jacob2016-01-162-3/+2
| | | | | | | | | | | | Reviewers: mjacob Subscribers: jholewinski, arsenm, dsanders, dblaikie Patch by Eduard Burtescu. Differential Revision: http://reviews.llvm.org/D16260 llvm-svn: 257999
* Re-commit r257064, after it was reverted in r257340.Silviu Baranga2016-01-151-3/+320
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This contains a fix for the issue that caused the revert: we no longer assume that we can insert instructions after the instruction that produces the base pointer. We previously assumed that this would be ok, because the instruction produces a value and therefore is not a terminator. This is false for invoke instructions. We will now insert these new instruction directly at the location of the users. Original commit message: [InstCombine] Look through PHIs, GEPs, IntToPtrs and PtrToInts to expose more constants when comparing GEPs Summary: When comparing two GEP instructions which have the same base pointer and one of them has a constant index, it is possible to only compare indices, transforming it to a compare with a constant. This removes one use for the GEP instruction with the constant index, can reduce register pressure and can sometimes lead to removing the comparisson entirely. InstCombine was already doing this when comparing two GEPs if the base pointers were the same. However, in the case where we have complex pointer arithmetic (GEPs applied to GEPs, PHIs of GEPs, conversions to or from integers, etc) the value of the original base pointer will be hidden to the optimizer and this transformation will be disabled. This change detects when the two sides of the comparison can be expressed as GEPs with the same base pointer, even if they don't appear as such in the IR. The transformation will convert all the pointer arithmetic to arithmetic done on indices and all the relevant uses of GEPs to GEPs with a common base pointer. The GEP comparison will be converted to a comparison done on indices. Reviewers: majnemer, jmolloy Subscribers: hfinkel, jevinskie, jmolloy, aadg, llvm-commits Differential Revision: http://reviews.llvm.org/D15146 llvm-svn: 257897
* Change isSafeToLoadUnconditionally arguments order. Separated from ↵Artur Pilipenko2016-01-151-2/+2
| | | | | | http://reviews.llvm.org/D10920. llvm-svn: 257894
* [InstCombine] Rewrite bswap/bitreverse handling completely.James Molloy2016-01-151-179/+8
| | | | | | | | | | | | | | There are several requirements that ended up with this design; 1. Matching bitreversals is too heavyweight for InstCombine and doesn't really need to be done so early. 2. Bitreversals and byteswaps are very related in their matching logic. 3. We want to implement support for matching more advanced bswap/bitreverse patterns like partial bswaps/bitreverses. 4. Bswaps are best matched early in InstCombine. The result of these is that a new utility function is created in Transforms/Utils/Local.h that can be configured to search for bswaps, bitreverses or both. InstCombine uses it to find only bswaps, CGP uses it to find only bitreversals. We can then extend the matching logic in one place only. llvm-svn: 257875
* function names start with a lower case letter ; NFCSanjay Patel2016-01-122-6/+6
| | | | llvm-svn: 257496
* Revert r257164 - it has caused spec2k6 failures in LTO modeSilviu Baranga2016-01-111-322/+3
| | | | llvm-svn: 257340
* InstCombineCompares.cpp: Fix a warning. [-Wbraced-scalar-init]NAKAMURA Takumi2016-01-081-1/+1
| | | | llvm-svn: 257167
* Re-commit r257064, this time with a fixed assertSilviu Baranga2016-01-081-3/+322
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In setInsertionPoint if the value is not a PHI, Instruction or Argument it should be a Constant, not a ConstantExpr. Original commit message: [InstCombine] Look through PHIs, GEPs, IntToPtrs and PtrToInts to expose more constants when comparing GEPs Summary: When comparing two GEP instructions which have the same base pointer and one of them has a constant index, it is possible to only compare indices, transforming it to a compare with a constant. This removes one use for the GEP instruction with the constant index, can reduce register pressure and can sometimes lead to removing the comparisson entirely. InstCombine was already doing this when comparing two GEPs if the base pointers were the same. However, in the case where we have complex pointer arithmetic (GEPs applied to GEPs, PHIs of GEPs, conversions to or from integers, etc) the value of the original base pointer will be hidden to the optimizer and this transformation will be disabled. This change detects when the two sides of the comparison can be expressed as GEPs with the same base pointer, even if they don't appear as such in the IR. The transformation will convert all the pointer arithmetic to arithmetic done on indices and all the relevant uses of GEPs to GEPs with a common base pointer. The GEP comparison will be converted to a comparison done on indices. Reviewers: majnemer, jmolloy Subscribers: hfinkel, jevinskie, jmolloy, aadg, llvm-commits Differential Revision: http://reviews.llvm.org/D15146 llvm-svn: 257164
* [InstCombine] insert a new shuffle in a safe place (PR25999)Sanjay Patel2016-01-081-10/+7
| | | | | | | | Limit this transform to a basic block and guard against PHIs. Hopefully, this fixes the remaining failures in PR25999: https://llvm.org/bugs/show_bug.cgi?id=25999 llvm-svn: 257133
* Revert r257064. It caused failures in some sanitizer tests.Silviu Baranga2016-01-071-322/+3
| | | | llvm-svn: 257069
* Fix build after r257064: we should be returning false, not nullptrSilviu Baranga2016-01-071-2/+2
| | | | llvm-svn: 257067
* [InstCombine] Look through PHIs, GEPs, IntToPtrs and PtrToInts to expose ↵Silviu Baranga2016-01-071-3/+322
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | more constants when comparing GEPs Summary: When comparing two GEP instructions which have the same base pointer and one of them has a constant index, it is possible to only compare indices, transforming it to a compare with a constant. This removes one use for the GEP instruction with the constant index, can reduce register pressure and can sometimes lead to removing the comparisson entirely. InstCombine was already doing this when comparing two GEPs if the base pointers were the same. However, in the case where we have complex pointer arithmetic (GEPs applied to GEPs, PHIs of GEPs, conversions to or from integers, etc) the value of the original base pointer will be hidden to the optimizer and this transformation will be disabled. This change detects when the two sides of the comparison can be expressed as GEPs with the same base pointer, even if they don't appear as such in the IR. The transformation will convert all the pointer arithmetic to arithmetic done on indices and all the relevant uses of GEPs to GEPs with a common base pointer. The GEP comparison will be converted to a comparison done on indices. Reviewers: majnemer, jmolloy Subscribers: hfinkel, jevinskie, jmolloy, aadg, llvm-commits Differential Revision: http://reviews.llvm.org/D15146 llvm-svn: 257064
* fix typo; NFCSanjay Patel2016-01-061-1/+1
| | | | llvm-svn: 256883
* [InstCombine] insert a new shuffle before its uses (PR26015)Sanjay Patel2016-01-051-8/+21
| | | | | | | | | | | | | | | | Although this solves the test case in PR26015: https://llvm.org/bugs/show_bug.cgi?id=26015 And may solve PR25999: https://llvm.org/bugs/show_bug.cgi?id=25999 ...I suspect this is not the best solution. I think we want to insert the new shuffle just ahead of the earliest ExtractElementInst that we're replacing, but I don't know how that should be implemented. Differential Revision: http://reviews.llvm.org/D15878 llvm-svn: 256857
* [Statepoints] Refactor GCRelocateOperands into an intrinsic wrapper. NFC.Manuel Jacob2016-01-051-2/+1
| | | | | | | | | | | | | | | Summary: This commit renames GCRelocateOperands to GCRelocateInst and makes it an intrinsic wrapper, similar to e.g. MemCpyInst. Also, all users of GCRelocateOperands were changed to use the new intrinsic wrapper instead. Reviewers: sanjoy, reames Subscribers: reames, sanjoy, llvm-commits Differential Revision: http://reviews.llvm.org/D15762 llvm-svn: 256811
* [InstructionCombining] prepareICWorklistFromFunction halts in infinite loop ↵Chen Li2016-01-041-3/+2
| | | | | | | | | | | | | | with instructions of token type Summary: This patch fixes a bug in prepareICWorklistFromFunction, where the loop becomes infinite with instructions of token type. The patch checks if the instruction is token type, and if so it updates EndInst with the current instruction. Reviewers: reames, majnemer Subscribers: llvm-commits, sanjoy Differential Revision: http://reviews.llvm.org/D15859 llvm-svn: 256792
* fix formatting; NFCSanjay Patel2015-12-301-8/+8
| | | | llvm-svn: 256645
OpenPOWER on IntegriCloud