| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101613 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101416 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
| |
is doing the right thing and codegen looks correct for both Thumb and Thumb2.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101410 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101392 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
|
| |
directly. In cases where there are two dyn_alloc in the same BB it would have caused the old SP value to be reused and badness ensues. rdar://7493908
llvm is generating poor code for dynamic alloca, I'll fix that later.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101383 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
tokenfactor in between the load/store. This allows us to
optimize test7 into:
_test7: ## @test7
## BB#0: ## %entry
movl (%rdx), %eax
## kill: SIL<def> ESI<kill>
movb %sil, 5(%rdi)
ret
instead of:
_test7: ## @test7
## BB#0: ## %entry
movl 4(%esp), %ecx
movl $-65281, %eax ## imm = 0xFFFFFFFFFFFF00FF
andl 4(%ecx), %eax
movzbl 8(%esp), %edx
shll $8, %edx
addl %eax, %edx
movl 12(%esp), %eax
movl (%eax), %eax
movl %edx, 4(%ecx)
ret
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101355 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
|
| |
This doesn't occur much at all, it only seems to formed in the case
when the trunc optimization kicks in due to phase ordering. In that
case it is saves a few bytes on x86-32.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101350 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
| |
and. This happens with the store->load narrowing stuff.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101348 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a load/or/and/store sequence into a narrower store when it is
safe. Daniel tells me that clang will start producing this sort
of thing with bitfields, and this does trigger a few dozen times
on 176.gcc produced by llvm-gcc even now.
This compiles code like CodeGen/X86/2009-05-28-DAGCombineCrash.ll
into:
movl %eax, 36(%rdi)
instead of:
movl $4294967295, %eax ## imm = 0xFFFFFFFF
andq 32(%rdi), %rax
shlq $32, %rcx
addq %rax, %rcx
movq %rcx, 32(%rdi)
and each of the testcases into a single store. Each of them used
to compile into craziness like this:
_test4:
movl $65535, %eax ## imm = 0xFFFF
andl (%rdi), %eax
shll $16, %esi
addl %eax, %esi
movl %esi, (%rdi)
ret
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101343 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101341 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101340 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101286 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
| |
does not have a legal type. The legalizer does not know how to handle those
nodes. Radar 7854640.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101282 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101182 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
| |
such that the entire second half is in memory. Radar 7855014.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101181 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101163 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
| |
instruction being optimized. There is no need to --I which can deref off start of the BB.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101162 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
| |
in a nightly tester.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101158 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
| |
patch by Sylvere Teissier!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101106 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
| |
relocation. rdar://7738756
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101085 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101081 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101079 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101077 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we have this situation:
jCC L1
jmp L2
L1:
...
L2:
...
We can get a small performance boost by emitting this instead:
jnCC L2
L1:
...
L2:
...
This testcase shows an example of this:
float func(float x, float y) {
double product = (double)x * y;
if (product == 0.0)
return product;
return product - 1.0;
}
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101075 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101023 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100879 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100876 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
directive are not aligned on 16 byte boundaries. This causes misaligned loads, as the generated assembly assumes this "default" alignment.
this patch disables .lcomm in favour of '.local .comm'
Patch by Kalle Raisklia!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100875 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100860 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
|
| |
e.g.
%RDI<def,dead> = MOV64rr %RAX<kill>, %EDI<imp-def>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100804 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
| |
i32 store of immediates.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100751 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
| |
ensure that the expansion is dominated by the increments of those loops.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100748 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100705 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
explicitly split into stride-and-offset pairs. Also, add the
ability to track multiple post-increment loops on the same expression.
This refines the concept of "normalizing" SCEV expressions used for
to post-increment uses, and introduces a dedicated utility routine for
normalizing and denormalizing expressions.
This fixes the expansion of expressions which are post-increment users
of more than one loop at a time. More broadly, this takes LSR another
step closer to being able to reason about more than one loop at a time.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100699 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
| |
those who don't build all targets.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100688 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100637 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
| |
MachineOperand::isIdenticalTo wasn't handling metadata operands.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100636 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100612 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
| |
This fixes the Bullet regression on i386/nocona.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100553 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100482 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100455 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100346 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100208 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
| |
in particular, they end up aligning strings at 16-byte boundaries, and
there's no way for GlobalOpt to check OptForSize.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100172 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
|
| |
adding it to CSE hash table since copies aren't being considered for CSE and they may be deleted.
rdar://7819990
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100170 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
| |
unaligned loads into aligned loads.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100166 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100165 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100137 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
|
| |
zero.
- Do not try to infer GV alignment unless its type is sized. It's not possible to infer alignment if it has opaque type.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100118 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
| |
hosts / targets.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100101 91177308-0d34-0410-b5e6-96231b3b80d8
|