| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 191112
|
| |
|
|
|
|
|
|
|
|
| |
(ptrtoint Y))
The GEP pattern is what SCEV expander emits for "ugly geps". The latter is what
you get for pointer subtraction in C code. The rest of instcombine already
knows how to deal with that so just canonicalize on that.
llvm-svn: 191090
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If "C1/X" were having multiple uses, the only benefit of this
transformation is to potentially shorten critical path. But it is at the
cost of instroducing additional div.
The additional div may or may not incur cost depending on how div is
implemented. If it is implemented using Newton–Raphson iteration, it dosen't
seem to incur any cost (FIXME). However, if the div blocks the entire
pipeline, that sounds to be pretty expensive. Let CodeGen to take care
this transformation.
This patch sees 6% on a benchmark.
rdar://15032743
llvm-svn: 191037
|
| |
|
|
|
|
| |
The code below can't handle any pointers. PR17293.
llvm-svn: 191036
|
| |
|
|
|
|
|
| |
To avoid regressions with bitfield optimizations, this slicing should take place
later, like ISel time.
llvm-svn: 190891
|
| |
|
|
|
|
|
|
|
|
| |
Some of this code is no longer necessary since int<->ptr casts are no
longer occur as of r187444.
This also fixes handling vectors of pointers, and adds a bunch of new
testcases for vectors and address spaces.
llvm-svn: 190885
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
other in memory.
The motivation was to get rid of truncate and shift right instructions that get
in the way of paired load or floating point load.
E.g.,
Consider the following example:
struct Complex {
float real;
float imm;
};
When accessing a complex, llvm was generating a 64-bits load and the imm field
was obtained by a trunc(lshr) sequence, resulting in poor code generation, at
least for x86.
The idea is to declare that two load instructions is the canonical form for
loading two arithmetic type, which are next to each other in memory.
Two scalar loads at a constant offset from each other are pretty
easy to detect for the sorts of passes that like to mess with loads.
<rdar://problem/14477220>
llvm-svn: 190870
|
| |
|
|
| |
llvm-svn: 190461
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Several architectures use the same instruction to perform both a comparison and
a subtract. The instruction selection framework does not allow to consider
different basic blocks to expose such fusion opportunities.
Therefore, these instructions are “merged” by CSE at MI IR level.
To increase the likelihood of CSE to apply in such situation, we reorder the
operands of the comparison, when they have the same complexity, so that they
matches the order of the most frequent subtract.
E.g.,
icmp A, B
...
sub B, A
<rdar://problem/14514580>
llvm-svn: 190352
|
| |
|
|
| |
llvm-svn: 190113
|
| |
|
|
| |
llvm-svn: 190093
|
| |
|
|
|
|
|
|
|
|
| |
"(icmp op i8 A, B)" is equivalent to "(icmp op i8 (A & 0xff), B)" as a
degenerate case. Allowing this as a "masked" comparison when analysing "(icmp)
&/| (icmp)" allows us to combine them in more cases.
rdar://problem/7625728
llvm-svn: 189931
|
| |
|
|
|
|
|
|
|
|
|
| |
Even in cases which aren't universally optimisable like "(A & B) != 0 && (A &
C) != 0", the masks can make one of the comparisons completely redundant. In
this case, since we've gone to the effort of spotting masked comparisons we
should combine them.
rdar://problem/7625728
llvm-svn: 189930
|
| |
|
|
|
|
|
|
| |
This is another one that doesn't matter much,
but uses the right GEP index types in the first
place.
llvm-svn: 189854
|
| |
|
|
|
|
|
| |
This doesn't actually matter, since alloca is always
0 address space, but this is more consistent.
llvm-svn: 189853
|
| |
|
|
|
|
|
|
|
| |
integer overflow.
PR17026. Also avoid undefined shifts and shift amounts larger than 64 bits
(those are always undef because we can't represent integer types that large).
llvm-svn: 189672
|
| |
|
|
| |
llvm-svn: 189524
|
| |
|
|
| |
llvm-svn: 188926
|
| |
|
|
| |
llvm-svn: 188723
|
| |
|
|
| |
llvm-svn: 188721
|
| |
|
|
| |
llvm-svn: 188720
|
| |
|
|
| |
llvm-svn: 188719
|
| |
|
|
|
|
| |
Re-add the inboundsless tests I didn't add originally
llvm-svn: 188710
|
| |
|
|
| |
llvm-svn: 188563
|
| |
|
|
|
|
|
|
|
|
|
| |
When both constants are positive or both constants are negative,
InstCombine already simplifies comparisons like this, but when
it's exactly zero and -1, the operand sorting ends up reversed
and the pattern fails to match. Handle that special case.
Follow up for rdar://14689217
llvm-svn: 188512
|
| |
|
|
|
|
|
| |
This path wasn't tested before without a datalayout,
so add some more tests and re-run with and without one.
llvm-svn: 188507
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use the pointer size if datalayout is available.
Use i64 if it's not, which is consistent with what other
places do when the pointer size is unknown.
The test doesn't really test this in a useful way
since it will be transformed to that later anyway,
but this now tests it for non-zero arrays and when
datalayout isn't available. The cases in
visitGetElementPtrInst should save an extra re-visit to
the newly created GEP since it won't need to cleanup after
itself.
llvm-svn: 188339
|
| |
|
|
| |
llvm-svn: 188338
|
| |
|
|
| |
llvm-svn: 188337
|
| |
|
|
|
|
|
|
|
|
| |
These functions used to assume that the lsb of an integer corresponds
to vector element 0, whereas for big-endian it's the other way around:
the msb is in the first element and the lsb is in the last element.
Fixes MultiSource/Benchmarks/mediabench/gsm/toast for z.
llvm-svn: 188155
|
| |
|
|
| |
llvm-svn: 187758
|
| |
|
|
| |
llvm-svn: 187462
|
| |
|
|
|
|
|
|
| |
It will now only convert the arguments / return value and call
the underlying function if the types are able to be bitcasted.
This avoids using fp<->int conversions that would occur before.
llvm-svn: 187444
|
| |
|
|
| |
llvm-svn: 187253
|
| |
|
|
|
|
|
| |
also worthwhile for it to look through FP extensions and truncations, whose
application commutes with fneg.
llvm-svn: 187249
|
| |
|
|
|
|
| |
for consistency.
llvm-svn: 187225
|
| |
|
|
| |
llvm-svn: 186759
|
| |
|
|
| |
llvm-svn: 186533
|
| |
|
|
| |
llvm-svn: 186301
|
| |
|
|
|
|
| |
size.
llvm-svn: 186274
|
| |
|
|
| |
llvm-svn: 186235
|
| |
|
|
|
|
|
|
| |
undef vector of the wrong type.
LGTM'd by Nick Lewycky on IRC.
llvm-svn: 186224
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 186095
|
| |
|
|
| |
llvm-svn: 185916
|
| |
|
|
|
|
|
|
|
|
| |
The following transforms are valid if -C is a power of 2:
(icmp ugt (xor X, C), ~C) -> (icmp ult X, C)
(icmp ult (xor X, C), -C) -> (icmp uge X, C)
These are nice, they get rid of the xor.
llvm-svn: 185915
|
| |
|
|
|
|
| |
Tests were added in r185910 somehow.
llvm-svn: 185912
|
| |
|
|
| |
llvm-svn: 185910
|
| |
|
|
|
|
|
|
|
| |
C1-X <u C2 -> (X|(C2-1)) == C1
C1-X >u C2 -> (X|C2) == C1
X-C1 <u C2 -> (X & -C2) == C1
X-C1 >u C2 -> (X & ~C2) == C1
llvm-svn: 185909
|
| |
|
|
|
|
|
|
|
|
|
| |
Back in r179493 we determined that two transforms collided with each
other. The fix back then was to reorder the transforms so that the
preferred transform would give it a try and then we would try the
secondary transform. However, it was noted that the best approach would
canonicalize one transform into the other, removing the collision and
allowing us to optimize IR given to us in that form.
llvm-svn: 185808
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This transform allows us to turn IR that looks like:
%1 = icmp eq i64 %b, 0
%2 = icmp ult i64 %a, %b
%3 = or i1 %1, %2
ret i1 %3
into:
%0 = add i64 %b, -1
%1 = icmp uge i64 %0, %a
ret i1 %1
which means we go from lowering:
cmpq %rsi, %rdi
setb %cl
testq %rsi, %rsi
sete %al
orb %cl, %al
ret
to lowering:
decq %rsi
cmpq %rdi, %rsi
setae %al
ret
llvm-svn: 185677
|