| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 93313
|
|
|
|
|
|
|
|
|
| |
different BlockAddress labels, but nothing semantically important.
Add a FIXME that BlockAddress codegen is broken if the LLVM BB has
an empty name (e.g. strip was run).
llvm-svn: 93303
|
|
|
|
| |
llvm-svn: 93286
|
|
|
|
|
|
| |
flag doesn't exist there, and this is an x86 test.
llvm-svn: 93279
|
|
|
|
|
|
|
|
| |
where the pre-extension values are available in the subreg of the result of the extension, replace the uses of the pre-extension value with the result + extract_subreg.
For now, this pass is fairly conservative. It only perform the replacement when both the pre- and post- extension values are used in the block. It will miss cases where the post-extension values are live, but not used.
llvm-svn: 93278
|
|
|
|
|
|
|
|
|
|
|
|
| |
in JT.
2) When cloning blocks for PHI or xor conditions, use
instsimplify to simplify the code as we go. This allows us to
squish common cases early in JT which opens up opportunities for
subsequent iterations, and allows it to completely simplify the
testcase.
llvm-svn: 93253
|
|
|
|
| |
llvm-svn: 93244
|
|
|
|
|
|
|
| |
on x86-64 linux with messages like this:
Error: Incorrect register `%r14' used with `l' suffix
llvm-svn: 93242
|
|
|
|
| |
llvm-svn: 93230
|
|
|
|
| |
llvm-svn: 93229
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
condition is a xor with a phi node. This eliminates nonsense
like this from 176.gcc in several places:
LBB166_84:
testl %eax, %eax
- setne %al
- xorb %cl, %al
- notb %al
- testb $1, %al
- je LBB166_85
+ je LBB166_69
+ jmp LBB166_85
This is rdar://7391699
llvm-svn: 93221
|
|
|
|
| |
llvm-svn: 93206
|
|
|
|
|
|
| |
autogen them after 93152 and 93191.
llvm-svn: 93204
|
|
|
|
|
|
| |
overlap, then select as an ADD instead.
llvm-svn: 93191
|
|
|
|
| |
llvm-svn: 93189
|
|
|
|
| |
llvm-svn: 93187
|
|
|
|
| |
llvm-svn: 93185
|
|
|
|
|
|
|
|
| |
BRCOND was constant folded.
This fixes PR5980.
llvm-svn: 93184
|
|
|
|
|
|
|
|
|
|
|
| |
has an immediate with at least 32 bits of leading zeros, to avoid needing to
materialize that immediate in a register first.
FileCheckize, tidy, and extend a testcase to cover this case.
This fixes rdar://7527390.
llvm-svn: 93160
|
|
|
|
|
|
|
|
| |
new AsmPrinter. This is perhaps less elegant than describing them
in terms of MOV32r0 and subreg operations, but it allows the
current register to rematerialize them.
llvm-svn: 93158
|
|
|
|
| |
llvm-svn: 93157
|
|
|
|
| |
llvm-svn: 93156
|
|
|
|
|
|
| |
allow the instruction to be 3address-fied if needed.
llvm-svn: 93152
|
|
|
|
|
|
|
|
| |
ignore alignment requirements for SIMD memory operands. This
is useful on architectures like the AMD 10h that do not trap on
unaligned references if a status bit is twiddled at startup time.
llvm-svn: 93151
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
good code on PR4216:
_test_bitfield: ## @test_bitfield
orl $32962, %edi
movl $4294941946, %eax
andq %rdi, %rax
ret
instead of:
_test_bitfield:
movl $4294941696, %ecx
movl %edi, %eax
orl $194, %edi
orl $32768, %eax
andq $250, %rdi
andq %rax, %rcx
movq %rdi, %rax
orq %rcx, %rax
ret
Evan is looking into the remaining andq+imm -> andl optimization.
llvm-svn: 93147
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BitsToClear case. This allows it to promote expressions which have an
and/or/xor after the lshr, promoting cases like test2 (from PR4216)
and test3 (random extample extracted from a spec benchmark).
clang now compiles the code in PR4216 into:
_test_bitfield: ## @test_bitfield
movl %edi, %eax
orl $194, %eax
movl $4294902010, %ecx
andq %rax, %rcx
orl $32768, %edi
andq $39936, %rdi
movq %rdi, %rax
orq %rcx, %rax
ret
instead of:
_test_bitfield: ## @test_bitfield
movl %edi, %eax
orl $194, %eax
movl $4294902010, %ecx
andq %rax, %rcx
shrl $8, %edi
orl $128, %edi
shlq $8, %rdi
andq $39936, %rdi
movq %rdi, %rax
orq %rcx, %rax
ret
which is still not great, but is progress.
llvm-svn: 93145
|
|
|
|
|
|
|
|
|
| |
new BitsToClear result which allows us to start promoting
expressions that end with a lshr-by-constant. This is
conservatively correct and better than what we had before
(see testcases) but still needs to be extended further.
llvm-svn: 93144
|
|
|
|
|
|
| |
the dest of the sext.
llvm-svn: 93128
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the zext dest type. This allows us to handle test52/53 in cast.ll,
and allows llvm-gcc to generate much better code for PR4216 in -m64
mode:
_test_bitfield: ## @test_bitfield
orl $32962, %edi
movl %edi, %eax
andl $-25350, %eax
ret
This also fixes a bug handling vector extends, ensuring that the
mask produced is a vector constant, not an integer constant.
llvm-svn: 93127
|
|
|
|
|
|
|
|
| |
elimination of a sign extend to be a win, which simplifies
the client of CanEvaluateSExtd, and allows us to eliminate
more casts (examples taken from real code).
llvm-svn: 93109
|
|
|
|
|
|
|
|
| |
lshr+ashr instead of trunc+sext. We want to avoid type
conversions whenever possible, it is easier to codegen expressions
without truncates and extensions.
llvm-svn: 93107
|
|
|
|
|
|
|
|
|
|
|
| |
1) don't try to optimize a sext or zext that is only used by a trunc, let
the trunc get optimized first. This avoids some pointless effort in
some common cases since instcombine scans down a block in the first pass.
2) Change the cost model for zext elimination to consider an 'and' cheaper
than a zext. This allows us to do it more aggressively, and for the next
patch to simplify the code quite a bit.
llvm-svn: 93097
|
|
|
|
|
|
| |
more expressions to be promoted and casts eliminated.
llvm-svn: 93096
|
|
|
|
| |
llvm-svn: 93069
|
|
|
|
| |
llvm-svn: 93068
|
|
|
|
|
|
|
|
| |
R11, and then asserting that the target was in R9. Since R9 isn't reserved for
the target anymore, and is used as an argument, this patch changes the
assertion.
llvm-svn: 93065
|
|
|
|
|
|
| |
so that unnamed blocks are handled.
llvm-svn: 93059
|
|
|
|
|
|
| |
base is the right expression type. This fixes PR5981.
llvm-svn: 93045
|
|
|
|
|
|
|
|
|
|
| |
really does need to be a vector type, because
TargetLowering::getOperationAction for SIGN_EXTEND_INREG uses that type,
and it needs to be able to distinguish between vectors and scalars.
Also, fix some more issues with legalization of vector casts.
llvm-svn: 93043
|
|
|
|
|
|
| |
results of the cmpxchg8b instructions are being thrown away when it branches back to the top of the checking loop. This means the loop always compares against the old value and this can result in a dead lock.
llvm-svn: 93028
|
|
|
|
|
|
| |
the input is already sign extended.
llvm-svn: 93019
|
|
|
|
|
|
|
| |
result int by 8 for the first byte. While normally harmless,
if the result is smaller than a byte, this shift is invalid.
llvm-svn: 93018
|
|
|
|
|
|
| |
replaced. Do not delete dead nodes again.
llvm-svn: 92988
|
|
|
|
| |
llvm-svn: 92964
|
|
|
|
| |
llvm-svn: 92963
|
|
|
|
|
|
|
| |
that feeds into a zext, similar to the patch I did yesterday for sext.
There is a lot of room for extension beyond this patch.
llvm-svn: 92962
|
|
|
|
|
|
|
|
|
|
| |
When folding a and(any_ext(load)) both the any_ext and the
load have to have only a single use.
This removes the anyext-uses.ll testcase which started failing
because it is unreduced and unclear what it is testing.
llvm-svn: 92950
|
|
|
|
| |
llvm-svn: 92943
|
|
|
|
| |
llvm-svn: 92931
|
|
|
|
|
|
|
|
|
|
| |
to an element of a vector in a static ctor) which occurs with an
unrelated patch I'm testing. Annoyingly, EvaluateStoreInto basically
does exactly the same stuff as InsertElement constant folding, but it
now handles vectors, and you can't insertelement into a vector. It
would be 'really nice' if GEP into a vector were not legal.
llvm-svn: 92889
|