| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
instead of signed integer constant.
llvm-svn: 72300
|
| |
|
|
|
|
|
|
| |
Instcombine to be more aggressive about using SimplifyDemandedBits
on shift nodes. This allows a shift to be simplified to zero in the
included test case.
llvm-svn: 72204
|
| |
|
|
|
|
|
| |
is not known to be nothrow. This allows readnone/readonly functions
to be deleted even if we don't know whether the callee can throw.
llvm-svn: 71676
|
| |
|
|
|
|
|
| |
will make it more obvious what it represents, and stop
it being confused with the StoreSize.
llvm-svn: 71349
|
| |
|
|
|
|
| |
preparation for the day we use null TargetData when no target is specified.
llvm-svn: 71210
|
| |
|
|
|
|
| |
types, such as loads and calls.
llvm-svn: 71175
|
| |
|
|
|
|
|
|
| |
the optimizers about this. For example, a readonly
function with no uses cannot be removed unless it is
also marked nounwind.
llvm-svn: 71071
|
| |
|
|
| |
llvm-svn: 70054
|
| |
|
|
|
|
|
| |
into unsigned ones when the operands are known to have the same
sign bit value.
llvm-svn: 70053
|
| |
|
|
| |
llvm-svn: 69946
|
| |
|
|
|
|
| |
pointer type, make sure that the pointer size is a valid sequential index type.
llvm-svn: 69574
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
integer types, unless they are already strange. This prevents it from
turning the code produced by SROA into crazy libcalls and stuff that
the code generator can't handle. In the attached example, the result
was an i96 multiply that caused the x86 backend to assert.
Note that if TargetData had an idea of what the legal types are for
a target that this could be used to stop instcombine from introducing
i64 muls, as Scott wanted.
llvm-svn: 68598
|
| |
|
|
| |
llvm-svn: 68500
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|