| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-%a + 42
into
42 - %a
previously we were emitting:
-(%a + 42)
This fixes the infinite loop in PR12338. The generated code is still not perfect, though.
Will work on that next
llvm-svn: 158237
|
|
|
|
|
|
| |
elements, which may disagree with the select condition type.
llvm-svn: 158166
|
|
|
|
|
|
|
| |
matter.
rdar://11579835
llvm-svn: 158084
|
|
|
|
| |
llvm-svn: 157592
|
|
|
|
|
|
|
|
|
|
|
|
| |
The test case feeds the following into InstCombine's visitSelect:
%tobool8 = icmp ne i32 0, 0
%phitmp = select i1 %tobool8, i32 3, i32 0
Then instcombine replaces the right side of the switch with 0, doesn't notice
that nothing changes and tries again indefinitely.
This fixes PR12897.
llvm-svn: 157587
|
|
|
|
| |
llvm-svn: 157556
|
|
|
|
|
|
| |
type's size.
llvm-svn: 157548
|
|
|
|
|
|
|
|
| |
move EmitGEPOffset from InstCombine to Transforms/Utils/Local.h
(a draft of this) patch reviewed by Andrew, thanks.
llvm-svn: 157261
|
|
|
|
|
|
|
|
| |
objectsize intrinsic.
After a lot of discussion, we realized it's not the best option for run-time bounds checking
llvm-svn: 157255
|
|
|
|
| |
llvm-svn: 156625
|
|
|
|
| |
llvm-svn: 156600
|
|
|
|
|
|
| |
add an additional parameter to InstCombiner::EmitGEPOffset() to force it to *not* emit operations with NUW flag
llvm-svn: 156585
|
|
|
|
|
|
|
| |
refactor code a bit to enable future changes to support run-time information
add support to compute allocation sizes at run-time if penalty > 1 (e.g., malloc(x), calloc(x, y), and VLAs)
llvm-svn: 156515
|
|
|
|
| |
llvm-svn: 156257
|
|
|
|
|
|
|
|
| |
case when alloca's size is calculated within the "add/sub/... nsw".
Also added fix to 2011-06-13-nsw-alloca.ll test.
llvm-svn: 156231
|
|
|
|
|
|
|
|
| |
being done for malloc)
fix a few typos found by Chad in my previous commit
llvm-svn: 156110
|
|
|
|
| |
llvm-svn: 156102
|
|
|
|
|
|
|
|
| |
there is no need to fallback to visitCallSite.
This gives a 0.9% in a test case
llvm-svn: 156069
|
|
|
|
|
|
|
|
|
| |
<rdar://problem/11291436>.
This is a second attempt at a fix for this, the first was r155468. Thanks
to Chandler, Bob and others for the feedback that helped me improve this.
llvm-svn: 155866
|
|
|
|
|
|
|
|
|
|
| |
(x & y) | (x ^ y) -> x | y
(x & y) + (x ^ y) -> x | y
Patch by Manman Ren.
rdar://10770603
llvm-svn: 155674
|
|
|
|
|
|
|
|
| |
in poor taste.
Talking through some alternate solutions with Chandler.
llvm-svn: 155530
|
|
|
|
|
|
| |
<rdar://problem/11291436>.
llvm-svn: 155468
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Original commit message:
Defer some shl transforms to DAGCombine.
The shl instruction is used to represent multiplication by a constant
power of two as well as bitwise left shifts. Some InstCombine
transformations would turn an shl instruction into a bit mask operation,
making it difficult for later analysis passes to recognize the
constsnt multiplication.
Disable those shl transformations, deferring them to DAGCombine time.
An 'shl X, C' instruction is now treated mostly the same was as 'mul X, C'.
These transformations are deferred:
(X >>? C) << C --> X & (-1 << C) (When X >> C has multiple uses)
(X >>? C1) << C2 --> X << (C2-C1) & (-1 << C2) (When C2 > C1)
(X >>? C1) << C2 --> X >>? (C1-C2) & (-1 << C2) (When C1 > C2)
The corresponding exact transformations are preserved, just like
div-exact + mul:
(X >>?,exact C) << C --> X
(X >>?,exact C1) << C2 --> X << (C2-C1)
(X >>?,exact C1) << C2 --> X >>?,exact (C1-C2)
The disabled transformations could also prevent the instruction selector
from recognizing rotate patterns in hash functions and cryptographic
primitives. I have a test case for that, but it is too fragile.
llvm-svn: 155362
|
|
|
|
|
|
|
|
|
| |
While the patch was perfect and defect free, it exposed a really nasty
bug in X86 SelectionDAG that caused an llc crash when compiling lencod.
I'll put the patch back in after fixing the SelectionDAG problem.
llvm-svn: 155181
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The shl instruction is used to represent multiplication by a constant
power of two as well as bitwise left shifts. Some InstCombine
transformations would turn an shl instruction into a bit mask operation,
making it difficult for later analysis passes to recognize the
constsnt multiplication.
Disable those shl transformations, deferring them to DAGCombine time.
An 'shl X, C' instruction is now treated mostly the same was as 'mul X, C'.
These transformations are deferred:
(X >>? C) << C --> X & (-1 << C) (When X >> C has multiple uses)
(X >>? C1) << C2 --> X << (C2-C1) & (-1 << C2) (When C2 > C1)
(X >>? C1) << C2 --> X >>? (C1-C2) & (-1 << C2) (When C1 > C2)
The corresponding exact transformations are preserved, just like
div-exact + mul:
(X >>?,exact C) << C --> X
(X >>?,exact C1) << C2 --> X << (C2-C1)
(X >>?,exact C1) << C2 --> X >>?,exact (C1-C2)
The disabled transformations could also prevent the instruction selector
from recognizing rotate patterns in hash functions and cryptographic
primitives. I have a test case for that, but it is too fragile.
llvm-svn: 155136
|
|
|
|
|
|
|
|
|
|
|
|
| |
GEPs, bit casts, and stores reaching it but no other instructions. These
often show up during the iterative processing of the inliner, SROA, and
DCE. Once we hit this point, we can completely remove the alloca. These
were actually showing up in the final, fully optimized code in a bunch
of inliner tests I've been working on, and notably they show up after
LLVM finishes optimizing away all function calls involved in
hash_combine(a, b).
llvm-svn: 154285
|
|
|
|
|
|
|
|
| |
This allows us to keep passing reduced masks to SimplifyDemandedBits, but
know about all the bits if SimplifyDemandedBits fails. This allows instcombine
to simplify cases like the one in the included testcase.
llvm-svn: 154011
|
|
|
|
|
|
| |
operand is of pointer type (and not vector type).
llvm-svn: 153468
|
|
|
|
| |
llvm-svn: 153465
|
|
|
|
| |
llvm-svn: 153458
|
|
|
|
| |
llvm-svn: 152935
|
|
|
|
|
|
|
|
|
|
| |
alignment. If that's the case, then we want to make sure that we don't increase
the alignment of the store instruction. Because if we increase it to be "more
aligned" than the pointer, code-gen may use instructions which require a greater
alignment than the pointer guarantees.
<rdar://problem/11043589>
llvm-svn: 152907
|
|
|
|
|
|
| |
checking for or-of-xor operations after those checks; a later check expects that any constant will be in Op1. PR12234.
llvm-svn: 152884
|
|
|
|
|
|
| |
is wasteful.
llvm-svn: 152794
|
|
|
|
|
|
|
| |
Renamed methods caseBegin, caseEnd and caseDefault with case_begin, case_end, and case_default.
Added some notes relative to case iterators.
llvm-svn: 152532
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120130/136146.html
Implemented CaseIterator and it solves almost all described issues: we don't need to mix operand/case/successor indexing anymore. Base iterator class is implemented as a template since it may be initialized either from "const SwitchInst*" or from "SwitchInst*".
ConstCaseIt is just a read-only iterator.
CaseIt is read-write iterator; it allows to change case successor and case value.
Usage of iterator allows totally remove resolveXXXX methods. All indexing convertions done automatically inside the iterator's getters.
Main way of iterator usage looks like this:
SwitchInst *SI = ... // intialize it somehow
for (SwitchInst::CaseIt i = SI->caseBegin(), e = SI->caseEnd(); i != e; ++i) {
BasicBlock *BB = i.getCaseSuccessor();
ConstantInt *V = i.getCaseValue();
// Do something.
}
If you want to convert case number to TerminatorInst successor index, just use getSuccessorIndex iterator's method.
If you want initialize iterator from TerminatorInst successor index, use CaseIt::fromSuccessorIndex(...) method.
There are also related changes in llvm-clients: klee and clang.
llvm-svn: 152297
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This transformation is not correct for not-equal conditions:
(trunc x) != C1 & (and x, CA) != C2 -> (and x, CA|CMAX) != C1|C2
Let
C1 == 0
C2 == 0
CA == 0xFF0000
CMAX == 0xFF
and truncating to i8.
The original truth table:
x | A: trunc x != 0 | B: x & 0xFF0000 != 0 | A & B != 0
--------------------------------------------------------------
0x00000 | 0 | 0 | 0
0x00001 | 1 | 0 | 0
0x10000 | 0 | 1 | 0
0x10001 | 1 | 1 | 1
The truth table of the replacement:
x | x & 0xFF00FF != 0
----------------------------
0x00000 | 0
0x00001 | 1
0x10000 | 1
0x10001 | 1
So they are different.
llvm-svn: 151691
|
|
|
|
| |
llvm-svn: 151056
|
|
|
|
|
|
|
|
|
|
|
| |
of the indices.
This transformation is not safe in some pathological cases (signed icmp of pointers should be an
extremely rare thing, but it's valid IR!). Add an explanatory comment.
Kudos to Duncan for pointing out this edge case (and not giving up explaining it until I finally got it).
llvm-svn: 151055
|
|
|
|
|
|
| |
when the GEPs are inbounds.
llvm-svn: 150978
|
|
|
|
|
|
|
|
| |
pointer but use different types, expand the offset calculation and to the compare on the offset if profitable.
This came up in SmallVector code.
llvm-svn: 150962
|
|
|
|
|
|
|
|
|
| |
- Ignore pointer casts.
- Also expand GEPs that aren't constantexprs when they have one use or only constant indices.
- We now compile "&foo[i] - &foo[j]" into "i - j".
llvm-svn: 150961
|
|
|
|
| |
llvm-svn: 150425
|
|
|
|
| |
llvm-svn: 149967
|
|
|
|
|
|
| |
instead of always using ConstantVector.
llvm-svn: 149912
|
|
|
|
|
|
| |
remove the code that handles them.
llvm-svn: 149901
|
|
|
|
| |
llvm-svn: 149865
|
|
|
|
| |
llvm-svn: 149650
|
|
|
|
| |
llvm-svn: 149649
|
|
|
|
|
|
| |
More targetted fix replacing d0e277d272d517ca1cda368267d199f0da7cad95.
llvm-svn: 149648
|