| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The instcombine recognized pattern looks like:
a = b * c
d = a +/- Cst
or
a = b * c
d = Cst +/- a
When creating the new operands for fadd or fsub instruction following the related fmul, the first operand was created with the second original operand (M0 was created with C1) and the second with the first (M1 with Opnd0).
The fix consists in creating the new operands with the appropriate original operand, i.e., M0 with Opnd0 and M1 with C1.
llvm-svn: 176300
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
some optimization opportunities (in the enclosing supper-expressions).
rule 1. (-0.0 - X ) * Y => -0.0 - (X * Y)
if expression "-0.0 - X" has only one reference.
rule 2. (0.0 - X ) * Y => -0.0 - (X * Y)
if expression "0.0 - X" has only one reference, and
the instruction is marked "noSignedZero".
2. Eliminate negation (The compiler was already able to handle these
opt if the 0.0s are replaced with -0.0.)
rule 3: (0.0 - X) * (0.0 - Y) => X * Y
rule 4: (0.0 - X) * C => X * -C
if the expr is flagged "noSignedZero".
3.
Rule 5: (X*Y) * X => (X*X) * Y
if X!=Y and the expression is flagged with "UnsafeAlgebra".
The purpose of this transformation is two-fold:
a) to form a power expression (of X).
b) potentially shorten the critical path: After transformation, the
latency of the instruction Y is amortized by the expression of X*X,
and therefore Y is in a "less critical" position compared to what it
was before the transformation.
4. Remove the InstCombine code about simplifiying "X * select".
The reasons are following:
a) The "select" is somewhat architecture-dependent, therefore the
higher level optimizers are not able to precisely predict if
the simplification really yields any performance improvement
or not.
b) The "select" operator is bit complicate, and tends to obscure
optimization opportunities. It is btter to keep it as low as
possible in expr tree, and let CodeGen to tackle the optimization.
llvm-svn: 172551
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
---------------------------------------------------------------------------
C_A: reassociation is allowed
C_R: reciprocal of a constant C is appropriate, which means
- 1/C is exact, or
- reciprocal is allowed and 1/C is neither a special value nor a denormal.
-----------------------------------------------------------------------------
rule1: (X/C1) / C2 => X / (C2*C1) (if C_A)
=> X * (1/(C2*C1)) (if C_A && C_R)
rule 2: X*C1 / C2 => X * (C1/C2) if C_A
rule 3: (X/Y)/Z = > X/(Y*Z) (if C_A && at least one of Y and Z is symbolic value)
rule 4: Z/(X/Y) = > (Z*Y)/X (similar to rule3)
rule 5: C1/(X*C2) => (C1/C2) / X (if C_A)
rule 6: C1/(X/C2) => (C1*C2) / X (if C_A)
rule 7: C1/(C2/X) => (C1/C2) * X (if C_A)
llvm-svn: 172488
|
| |
|
|
|
|
| |
Thank Eric Christopher for figuring out these problems!
llvm-svn: 171805
|
| |
|
|
|
|
|
|
|
|
|
| |
o. X/C1 * C2 => X * (C2/C1) (if C2/C1 is neither special FP nor denormal)
o. X/C1 * C2 -> X/(C1/C2) (if C2/C1 is either specical FP or denormal, but C1/C2 is a normal Fp)
Let MDC denote multiplication or dividion with one & only one operand being a constant
o. (MDC ± C1) * C2 => (MDC * C2) ± (C1 * C2)
(so long as the constant-folding doesn't yield any denormal or special value)
llvm-svn: 171793
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long standing point
of file layout clutter in LLVM.
There are still more header files to move here, but I wanted to handle
them in separate commits to make tracking what files make sense at each
layer easier.
The only really questionable files here are the target intrinsic
tablegen files. But that's a battle I'd rather not fight today.
I've updated both CMake and Makefile build systems (I think, and my
tests think, but I may have missed something).
I've also re-sorted the includes throughout the project. I'll be
committing updates to Clang, DragonEgg, and Polly momentarily.
llvm-svn: 171366
|
| |
|
|
|
|
| |
Implement rule : "x * (select cond 1.0, 0.0) -> select cond x, 0.0"
llvm-svn: 170226
|
| |
|
|
|
|
|
|
| |
In a previous thread it was pointed out that isPowerOfTwo is not a very precise
name since it can return false for powers of two if it is unable to show that
they are powers of two.
llvm-svn: 170093
|
| |
|
|
|
|
|
|
|
|
| |
been used in the first place. It simply was passed to the function and to the
recursive invocations. Simply drop the parameter and update the callers for the
new signature.
Patch by Saleem Abdulrasool!
llvm-svn: 169988
|
| |
|
|
|
|
| |
functions from SimplifyInstruction
llvm-svn: 169941
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.
Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]
llvm-svn: 169131
|
| |
|
|
|
|
| |
nested ifs
llvm-svn: 169049
|
| |
|
|
| |
llvm-svn: 169043
|
| |
|
|
|
|
| |
reviewed by Michael Ilseman <milseman@apple.com>
llvm-svn: 169025
|
| |
|
|
| |
llvm-svn: 165402
|
| |
|
|
|
|
| |
See: http://en.wikipedia.org/wiki/If_and_only_if Commit 164767
llvm-svn: 164768
|
| |
|
|
| |
llvm-svn: 164767
|
| |
|
|
|
|
|
|
| |
a value that is zext'd.
Fixes PR13250.
llvm-svn: 164377
|
| |
|
|
| |
llvm-svn: 162911
|
| |
|
|
|
|
|
|
| |
because C always rounds towards zero.
Thanks Dirk and Ben.
llvm-svn: 162899
|
| |
|
|
|
|
|
|
|
| |
the bit width.
No test case, undefined shifts get folded early, but can occur when other
transforms generate a constant. Thanks to Duncan for bringing this up.
llvm-svn: 162755
|
| |
|
|
|
|
| |
and non-const shifts.
llvm-svn: 162751
|
| |
|
|
|
|
| |
Thanks Benjamin for noticing this.
llvm-svn: 162749
|
| |
|
|
|
|
|
|
|
|
| |
For example:
%1 = lshr i32 %x, 2
%2 = udiv i32 %1, 100
rdar://12182093
llvm-svn: 162743
|
| |
|
|
|
|
| |
rdar://11721329
llvm-svn: 158946
|
| |
|
|
|
|
| |
instead of always using ConstantVector.
llvm-svn: 149912
|
| |
|
|
|
|
|
| |
we should (theoretically optimize and codegen ConstantDataVector as well
as ConstantVector.
llvm-svn: 149116
|
| |
|
|
| |
llvm-svn: 148929
|
| |
|
|
|
|
| |
Fixes r8429
llvm-svn: 144036
|
| |
|
|
|
|
|
|
| |
to be uniqued, without any benefit.
If someone prefers %tmp42 to %42, run instnamer.
llvm-svn: 140634
|
| |
|
|
| |
llvm-svn: 135375
|
| |
|
|
| |
llvm-svn: 135251
|
| |
|
|
| |
llvm-svn: 132402
|
| |
|
|
| |
llvm-svn: 132351
|
| |
|
|
|
|
|
| |
sub with a non-constant. Fix comments, enlarge test case.
rdar://problem/6501862
llvm-svn: 132348
|
| |
|
|
|
|
| |
rdar://problem/6501862
llvm-svn: 132316
|
| |
|
|
|
|
|
|
| |
shift-exactness
xform recurse.
llvm-svn: 131888
|
| |
|
|
|
|
| |
in a known-non-zero context.
llvm-svn: 131887
|
| |
|
|
|
|
|
|
| |
checking
for a constant directly. Thanks to Duncan for pointing this out.
llvm-svn: 131885
|
| |
|
|
| |
llvm-svn: 131862
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
that their
result is non-zero. Implement an example optimization (PR9814), which allows us to
transform:
A / ((1 << B) >>u 2)
into:
A >>u (B-2)
which we compile into:
_divu3: ## @divu3
leal -2(%rsi), %ecx
shrl %cl, %edi
movl %edi, %eax
ret
instead of:
_divu3: ## @divu3
movb %sil, %cl
movl $1, %esi
shll %cl, %esi
shrl $2, %esi
movl %edi, %eax
xorl %edx, %edx
divl %esi, %eax
ret
llvm-svn: 131860
|
| |
|
|
| |
llvm-svn: 130705
|
| |
|
|
|
|
|
| |
This automagically provides a transform noticed by my super-optimizer
as occurring quite often: "rem x, (select cond, x, 1)" -> 0.
llvm-svn: 130694
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
urem or constant B.
This obviously helps a lot if the division would be turned into a libcall
(think i64 udiv on i386), but div is also one of the few remaining instructions
on modern CPUs that become more expensive when the bitwidth gets bigger.
This also helps register pressure on i386 when dividing chars, divb needs
two 8-bit parts of a 16 bit register as input where divl uses two registers.
int foo(unsigned char a) { return a/10; }
int bar(unsigned char a, unsigned char b) { return a/b; }
compiles into (x86_64)
_foo:
imull $205, %edi, %eax
shrl $11, %eax
ret
_bar:
movzbl %dil, %eax
divb %sil, %al
movzbl %al, %eax
ret
llvm-svn: 130615
|
| |
|
|
|
|
| |
This folds away silly stuff like (a&255)/1000 -> 0.
llvm-svn: 130614
|
| |
|
|
|
|
|
|
| |
fmul.
Fixes PR9587.
llvm-svn: 128546
|
| |
|
|
|
|
|
|
|
|
|
| |
exact/nsw/nuw shifts and have instcombine infer them when it can prove
that the relevant properties are true for a given shift without them.
Also, a variety of refactoring to use the new patternmatch logic thrown
in for good luck. I believe that this takes care of a bunch of related
code quality issues attached to PR8862.
llvm-svn: 125267
|
| |
|
|
|
|
|
|
| |
instcombine xform to exercise this.
Nothing forms exact udivs yet though. This is progress on PR8862
llvm-svn: 124992
|
| |
|
|
| |
llvm-svn: 124535
|
| |
|
|
| |
llvm-svn: 124534
|