summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/AggressiveInstCombine/AggressiveInstCombine.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [LLVM-C] Fix name mangling on AggressiveInstCombinewhitequark2018-07-171-0/+1
| | | | | | | | | | | | | | Similarly to rL336736, at least one more C API function does not properly get declared as extern "C" due to a missing header, causing name mangling and linking errors. This patch fixes calls to LLVMAddAggressiveInstCombinerPass(). Differential Revision: https://reviews.llvm.org/D49416 Reviewed By: whitequark llvm-svn: 337264
* Sort includes + include a missing `extern "C"` headerGeorge Burgess IV2018-07-101-1/+2
| | | | | | | | | | If we don't include Initialization.h, `LLVMInitializeAggressiveInstCombiner` won't see its `extern "C"` decl. This causes sadness, name mangling, and linker errors. Reported on the mailing lists by Vladimir Vissoultchev. Thanks! llvm-svn: 336736
* Move Analysis/Utils/Local.h back to TransformsDavid Blaikie2018-06-041-1/+1
| | | | | | | | | | Review feedback from r328165. Split out just the one function from the file that's used by Analysis. (As chandlerc pointed out, the original change only moved the header and not the implementation anyway - which was fine for the one function that was used (since it's a template/inlined in the header) but not in general) llvm-svn: 333954
* [AggressiveInstCombine] avoid crashing on unsimplified code (PR37446)Sanjay Patel2018-05-141-0/+4
| | | | | | | | | This bug: https://bugs.llvm.org/show_bug.cgi?id=37446 ...raises another question: why do we run aggressive-instcombine before regular instcombine? llvm-svn: 332243
* [AggressiveInstCombine] convert a chain of 'and-shift' bits into masked compareSanjay Patel2018-05-091-32/+81
| | | | | | | | | | | | | | | | | | | | | | This is a follow-up to D45986. As suggested there, we should match the "all-bits-set" pattern in addition to "any-bits-set". This was a little more complicated than I thought it would be initially because the "and 1" instruction can be anywhere in the chain. Hopefully, the code comments make that logic understandable, but if you see a way to simplify or improve that, it's most appreciated. This transforms patterns that emerge from bitfield tests as seen in PR37098: https://bugs.llvm.org/show_bug.cgi?id=37098 I think it would also help reduce the large test from: D46336 D46595 but we need something to reassociate that case to the forms we're expecting here first. Differential Revision: https://reviews.llvm.org/D46649 llvm-svn: 331937
* Fix '32-bit shift implicitly converted to 64 bits' warning by using ↵Simon Pilgrim2018-05-021-1/+1
| | | | | | APInt::setBit instead. llvm-svn: 331359
* [AggressiveInstCombine] convert a chain of 'or-shift' bits into masked compareSanjay Patel2018-05-011-21/+94
| | | | | | | | | | | | | | | | | | | | | and (or (lshr X, C), ...), 1 --> (X & C') != 0 I initially thought about implementing the minimal pattern in instcombine as mentioned here: https://bugs.llvm.org/show_bug.cgi?id=37098#c6 ...but we need to do better to catch the more general sequence from the motivating test (more than 2 bits in the compare). And a test-suite run with statistics showed that this pattern only happened 2 times currently. It would potentially happen more often if reassociation worked better (D45842), but it's probably still not too frequent? This is small enough that I didn't see a need to create a whole new class/file within AggressiveInstCombine. There are likely other relatively small matchers like what was discussed in D44266 that would slide under foldUnusualPatterns() (name suggestions welcome). We could potentially also consolidate matchers for ctpop, bswap, etc under here. Differential Revision: https://reviews.llvm.org/D45986 llvm-svn: 331311
* Fix some layering in AggressiveInstCombine (avoiding inclusion of Scalar.h)David Blaikie2018-04-241-1/+5
| | | | llvm-svn: 330726
* [AggressiveInstCombine] Add aggressive inst combiner to the LLVM C API.Craig Topper2018-04-241-0/+4
| | | | | | I just tried to copy what was done for regular InstCombine. Hopefully I didn't miss anything. llvm-svn: 330668
* [AggressiveInstCombine] Add library initializer routine for ↵Craig Topper2018-04-241-0/+5
| | | | | | | | AggressiveInstCombine library. Use it in bugpoint and llvm-opt-fuzzer to match regular InstCombine. This should make aggressive instcombine usable with these tools. llvm-svn: 330663
* [AggressiveInstCombine] Make TruncCombine class ignore unreachable basic blocks.Amjad Aboud2018-01-311-2/+8
| | | | | | | | | Because dead code may contain non-standard IR that causes infinite looping or crashes in underlying analysis. See PR36134 for more details. Differential Revision: https://reviews.llvm.org/D42683 llvm-svn: 323862
* Another try to commit 323321 (aggressive instruction combine).Amjad Aboud2018-01-251-0/+110
| | | | llvm-svn: 323416
* Reverted 323321.Amjad Aboud2018-01-241-110/+0
| | | | llvm-svn: 323326
* [InstCombine] Introducing Aggressive Instruction Combine pass ↵Amjad Aboud2018-01-241-0/+110
(-aggressive-instcombine). Combine expression patterns to form expressions with fewer, simple instructions. This pass does not modify the CFG. For example, this pass reduce width of expressions post-dominated by TruncInst into smaller width when applicable. It differs from instcombine pass in that it contains pattern optimization that requires higher complexity than the O(1), thus, it should run fewer times than instcombine pass. Differential Revision: https://reviews.llvm.org/D38313 llvm-svn: 323321
OpenPOWER on IntegriCloud