| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
most important of these are cases in the generic logic for combining BinaryOperators.
This logic hadn't been updated to handle FastMathFlags, and it took me a while to detect it because it doesn't show up in a simple search for CreateFAdd.
llvm-svn: 199629
|
| |
|
|
|
|
| |
Also make them vector-aware.
llvm-svn: 199608
|
| |
|
|
| |
llvm-svn: 199605
|
| |
|
|
|
|
| |
the real thing.
llvm-svn: 199604
|
| |
|
|
|
|
| |
vectors.
llvm-svn: 199602
|
| |
|
|
| |
llvm-svn: 199598
|
| |
|
|
|
|
| |
...)) just because the function has multiple return values even if their return types are the same. Patch by Eduard Burtescu!
llvm-svn: 199564
|
| |
|
|
|
|
|
|
| |
vectors too.
PR18532.
llvm-svn: 199553
|
| |
|
|
|
|
| |
instructions. All found by inspection (aka grep).
llvm-svn: 199528
|
| |
|
|
|
|
| |
expressions.
llvm-svn: 199427
|
| |
|
|
|
|
| |
to reciprocal multiply transformation.
llvm-svn: 199425
|
| |
|
|
|
|
| |
optimizing an FMUL expression.
llvm-svn: 199424
|
| |
|
|
|
|
| |
LLVM expresses as (fsub -0.0, X).
llvm-svn: 199420
|
| |
|
|
| |
llvm-svn: 199254
|
| |
|
|
|
|
| |
Bitcasts can't be between address spaces anymore.
llvm-svn: 199253
|
| |
|
|
|
|
| |
insert element in instruction combine.
llvm-svn: 198730
|
| |
|
|
|
|
| |
links may not be permanent.
llvm-svn: 197713
|
| |
|
|
|
|
|
|
|
| |
This change fixes the case of arithmetic shift right - do not attempt to fold that case.
This change also relaxes the conditions when attempting to fold the logical shift right and shift left cases.
No additional IR-level test cases included at this time. See http://llvm.org/bugs/show_bug.cgi?id=17827 for proofs that these are correct transformations.
llvm-svn: 197705
|
| |
|
|
| |
llvm-svn: 196638
|
| |
|
|
|
|
|
|
| |
ConstantExpr can evaluate to false even when isNullValue gives false.
Fixes PR18143.
llvm-svn: 196611
|
| |
|
|
|
|
| |
change intended.
llvm-svn: 196164
|
| |
|
|
|
|
| |
functional change intended.
llvm-svn: 196163
|
| |
|
|
| |
llvm-svn: 196161
|
| |
|
|
|
|
| |
sequence where the shift is logical unless the comparison is unsigned
llvm-svn: 196129
|
| |
|
|
| |
llvm-svn: 195934
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
InstCombine, in visitFPTrunc, applies the following optimization to sqrt calls:
(fptrunc (sqrt (fpext x))) -> (sqrtf x)
but does not apply the same optimization to llvm.sqrt. This is a problem
because, to enable vectorization, Clang generates llvm.sqrt instead of sqrt in
fast-math mode, and because this optimization is being applied to sqrt and not
applied to llvm.sqrt, sometimes the fast-math code is slower.
This change makes InstCombine apply this optimization to llvm.sqrt as well.
This fixes the specific problem in PR17758, although the same underlying issue
(optimizations applied to libcalls are not applied to intrinsics) exists for
other optimizations in SimplifyLibCalls.
llvm-svn: 194935
|
| |
|
|
|
|
| |
This is common in bitfield code.
llvm-svn: 194925
|
| |
|
|
| |
llvm-svn: 194786
|
| |
|
|
| |
llvm-svn: 194537
|
| |
|
|
|
|
| |
that K1 and K2 are 'one-hot' (only one bit is on).
llvm-svn: 194525
|
| |
|
|
|
|
|
|
| |
When the elements are extracted from a select on vectors
or a vector select, do the select on the extracted scalars
from the input if there is only one use.
llvm-svn: 194013
|
| |
|
|
|
|
| |
x86_sse42_crc32_32_8 and was not mapped to a clang builtin. I'm not even sure why this form of the instruction is even called out explicitly in the docs. Also add AutoUpgrade support to convert it into the other intrinsic with appropriate trunc and zext.
llvm-svn: 192672
|
| |
|
|
|
|
| |
was a constant. This has a number of benefits, including producing small immediates (easier to materialize, smaller constant pools) as well as being more likely to allow the fptrunc to fuse with a preceding instruction (truncating selects are unusual).
llvm-svn: 191929
|
| |
|
|
| |
llvm-svn: 191920
|
| |
|
|
|
|
|
| |
The test's output doesn't change, but this ensures
this is actually hit with a different address space.
llvm-svn: 191701
|
| |
|
|
| |
llvm-svn: 191699
|
| |
|
|
|
|
|
|
|
| |
RAII helper.
Defines away the issue where cast<Instruction> would fail because constant
folding happened. Also slightly cleaner.
llvm-svn: 191674
|
| |
|
|
|
|
|
|
|
| |
when it was actually a Constant*.
There are quite a few other casts to Instruction that might have the same problem,
but this is the only one I have a test case for.
llvm-svn: 191668
|
| |
|
|
| |
llvm-svn: 191574
|
| |
|
|
|
|
|
|
|
|
| |
Currently foldSelectICmpAndOr asserts if the "or" involves a vector
containing several of the same power of two. We can easily avoid this by
only performing the fold on integer types, like foldSelectICmpAnd does.
Fixes <rdar://problem/15012516>
llvm-svn: 191552
|
| |
|
|
| |
llvm-svn: 191309
|
| |
|
|
| |
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
|