| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
not generate selects of two constants unless they are selects of 0 and 1.
e.g.
define i32 @t1(i32 %c, i32 %x) nounwind {
%t1 = icmp eq i32 %c, 0
%t2 = lshr i32 %x, 18
%t3 = select i1 %t1, i32 %t2, i32 %x
ret i32 %t3
}
was turned into
define i32 @t2(i32 %c, i32 %x) nounwind {
%t1 = icmp eq i32 %c, 0
%t2 = select i1 %t1, i32 18, i32 0
%t3 = lshr i32 %x, %t2
ret i32 %t3
}
For most targets, that means materializing two constants and then a select. e.g. On x86-64
movl %esi, %eax
shrl $18, %eax
testl %edi, %edi
cmovne %esi, %eax
ret
=>
xorl %eax, %eax
testl %edi, %edi
movl $18, %ecx
cmovne %eax, %ecx
movl %esi, %eax
shrl %cl, %eax
ret
Also, the optimizer and codegen can reason about shl / and / add, etc. by a constant. This optimization will hinder optimizations using ComputeMaskedBits.
llvm-svn: 68142
|
|
|
|
|
|
| |
precise than it used to be.
llvm-svn: 67662
|
|
|
|
| |
llvm-svn: 67657
|
|
|
|
|
|
|
|
| |
to/from integer types that are not intptr_t to convert to intptr_t
then do an integer conversion to the dest type. This exposes the
cast to the optimizer.
llvm-svn: 67638
|
|
|
|
|
|
|
|
|
|
|
| |
1. Make instcombine always canonicalize trunc x to i1 into an icmp(x&1). This
exposes the AND to other instcombine xforms and is more of what the code
generator expects.
2. Rewrite the remaining trunc pattern match to use 'match', which
simplifies it a lot.
llvm-svn: 67635
|
|
|
|
| |
llvm-svn: 67454
|
|
|
|
|
|
| |
shifts together. This fixes PR3851.
llvm-svn: 67411
|
|
|
|
|
|
|
|
|
| |
linkage: the value may be replaced with something
different at link time. (Frontends that want to
allow values to be loaded out of weak constants can
give their constants weak_odr linkage).
llvm-svn: 67407
|
|
|
|
|
|
| |
ComputeNumSignBits on a vector.
llvm-svn: 67211
|
|
|
|
| |
llvm-svn: 67089
|
|
|
|
| |
llvm-svn: 66930
|
|
|
|
| |
llvm-svn: 66867
|
|
|
|
| |
llvm-svn: 66866
|
|
|
|
|
|
|
|
| |
allocations. Apparently the assumption is there is an
instruction (terminator?) following the allocation so I
am allowing the same assumption.
llvm-svn: 66716
|
|
|
|
|
|
|
| |
another instcombine pass if we weren't going to make
one without debug info.
llvm-svn: 66576
|
|
|
|
|
|
| |
instead of a Constant*, which is what the clients of it really want.
llvm-svn: 66364
|
|
|
|
|
|
|
| |
parent between MemCpyInst and MemMoveInst, simplify some code to
use it.
llvm-svn: 66361
|
|
|
|
|
|
|
| |
codegen. I convinced myself it was OK to skip all
pointer bitcasts here too.
llvm-svn: 66122
|
|
|
|
|
|
| |
had 2 uses instead of 1.
llvm-svn: 66112
|
|
|
|
|
|
| |
per Chris' suggestion. Slightly faster.
llvm-svn: 65999
|
|
|
|
|
|
| |
when counting work; it was only off by 1.
llvm-svn: 65993
|
|
|
|
|
|
|
| |
feed into llvm.dbg.declare nodes, as well as
the debug directives themselves.
llvm-svn: 65976
|
|
|
|
|
|
|
|
| |
use, check also for the case where it has two uses,
the other being a llvm.dbg.declare. This is needed so
debug info doesn't affect codegen.
llvm-svn: 65970
|
|
|
|
|
|
| |
and put @file directives on their own comment line.
llvm-svn: 65920
|
|
|
|
|
|
| |
(lest they affect codegen).
llvm-svn: 65915
|
|
|
|
|
|
|
|
| |
info with it.
Don't count debug info insns against the scan maximum
in FindAvailableLoadedValue (lest they affect codegen).
llvm-svn: 65910
|
|
|
|
|
|
| |
clean up when using variable length arrays in llvm-gcc.
llvm-svn: 65832
|
|
|
|
|
|
| |
are always set by reference on the path that uses them.) No functional change.
llvm-svn: 65621
|
|
|
|
| |
llvm-svn: 65464
|
|
|
|
|
|
|
| |
ashr instcombine to help expose this code. And apply the fix to
SelectionDAG's copy of this code too.
llvm-svn: 65364
|
|
|
|
| |
llvm-svn: 65314
|
|
|
|
| |
llvm-svn: 65306
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
memcpy to match the alignment of the destination. It isn't necessary
for making loads and stores handled like the SSE loadu/storeu
intrinsics, and it was causing a performance regression in
MultiSource/Applications/JM/lencod.
The problem appears to have been a memcpy that copies from some
highly aligned array into an alloca; the alloca was then being
assigned a large alignment, which required codegen to perform
dynamic stack-pointer re-alignment, which forced the enclosing
function to have a frame pointer, which led to increased spilling.
llvm-svn: 65289
|
|
|
|
|
|
| |
load(bitcast(char[4] to i32*)) evaluation.
llvm-svn: 65246
|
|
|
|
|
|
|
|
| |
as legality. Make load sinking and gep sinking more careful: we only
do it when it won't pessimize loads from the stack. This has the added
benefit of not producing code that is unanalyzable to SROA.
llvm-svn: 65209
|
|
|
|
|
|
|
| |
eliminate all the extensions and all but the one required truncate
from the testcase, but the or/and/shift stuff still isn't zapped.
llvm-svn: 64809
|
|
|
|
|
|
| |
of an alloca or global variable.
llvm-svn: 64693
|
|
|
|
|
|
|
|
| |
Enhance instcombine to use the preferred field of
GetOrEnforceKnownAlignment in more cases, so that regular IR operations are
optimized in the same way that the intrinsics currently are.
llvm-svn: 64623
|
|
|
|
|
|
|
|
| |
they do not have to be the same
width as the result value.
llvm-svn: 64335
|
|
|
|
|
|
| |
changes the address space of the pointer.
llvm-svn: 64035
|
|
|
|
|
|
| |
64 elements.
llvm-svn: 63631
|
|
|
|
| |
llvm-svn: 63500
|
|
|
|
|
|
|
| |
turn icmp eq a+x, b+x into icmp eq a, b if a+x or b+x has other uses. This
may have been increasing register pressure leading to the bzip2 slowdown.
llvm-svn: 63487
|
|
|
|
|
|
|
|
|
|
|
| |
improvements to the EvaluateInDifferentType code. This code works
by just inserted a bunch of new code and then seeing if it is
useful. Instcombine is not allowed to do this: it can only insert
new code if it is useful, and only when it is converging to a more
canonical fixed point. Now that we iterate when DCE makes progress,
this causes an infinite loop when the code ends up not being used.
llvm-svn: 63483
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
simplifydemandedbits to simplify instructions with *multiple
uses* in contexts where it can get away with it. This allows
it to simplify the code in multi-use-or.ll into a single 'add
double'.
This change is particularly interesting because it will cover
up for some common codegen bugs with large integers created due
to the recent SROA patch. When working on fixing those bugs,
this should be disabled.
llvm-svn: 63481
|
|
|
|
| |
llvm-svn: 63480
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now, if it detects that "V" is the same as some other value,
SimplifyDemandedBits returns the new value instead of RAUW'ing it immediately.
This has two benefits:
1) simpler code in the recursive SimplifyDemandedBits routine.
2) it allows future fun stuff in instcombine where an operation has multiple
uses and can be simplified in one context, but not all.
#2 isn't implemented yet, this patch should have no functionality change.
llvm-svn: 63479
|
|
|
|
| |
llvm-svn: 63477
|
|
|
|
|
|
|
| |
not doing so prevents it from properly iterating and prevents it
from deleting the entire body of dce-iterate.ll
llvm-svn: 63476
|
|
|
|
|
|
| |
has a different number of elements than the output.
llvm-svn: 62998
|