| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
types such as i33 were rounded to i32. Originated from Duncan's testcase.
llvm-svn: 132893
|
|
|
|
| |
llvm-svn: 132872
|
|
|
|
| |
llvm-svn: 132871
|
|
|
|
| |
llvm-svn: 132681
|
|
|
|
|
|
|
|
|
| |
(only happens when using the -promote-elements option).
The correct legalization order is to first try to promote element. Next, we try
to widen vectors.
llvm-svn: 132648
|
|
|
|
|
|
| |
Part of rdar://9119939
llvm-svn: 132510
|
|
|
|
| |
llvm-svn: 132479
|
|
|
|
| |
llvm-svn: 132424
|
|
|
|
|
|
| |
rdar://problem/5660695
llvm-svn: 132411
|
|
|
|
| |
llvm-svn: 132396
|
|
|
|
|
|
|
|
|
| |
patch we add a flag to enable a new type legalization decision - to promote
integer elements in vectors. Currently, the rest of the codegen does not support
this kind of legalization. This flag will be removed when the transition is
complete.
llvm-svn: 132394
|
|
|
|
|
|
|
|
|
|
|
| |
LegalizeTypeAction.
This patch does not change the behavior of the type legalizer. The codegen
produces the same code.
This infrastructural change is needed in order to enable complex decisions
for vector types (needed by the vector-select patch).
llvm-svn: 132263
|
|
|
|
|
|
| |
code in one place. Re-apply 131534 and fix the multi-step promotion of integers.
llvm-svn: 132217
|
|
|
|
| |
llvm-svn: 131663
|
|
|
|
|
|
|
|
| |
Original log entry:
Refactor getActionType and getTypeToTransformTo ; place all of the 'decision'
code in one place.
llvm-svn: 131536
|
|
|
|
|
|
| |
code in one place.
llvm-svn: 131534
|
|
|
|
|
|
| |
Patch by Evan Cheng.
llvm-svn: 131093
|
|
|
|
|
|
| |
functionality change.
llvm-svn: 131012
|
|
|
|
|
|
|
|
|
|
|
|
| |
On x86 this allows to fold a load into the cmp, greatly reducing register pressure.
movzbl (%rdi), %eax
cmpl $47, %eax
->
cmpb $47, (%rdi)
This shaves 8k off gcc.o on i386. I'll leave applying the patch in README.txt to Chris :)
llvm-svn: 130005
|
|
|
|
|
|
| |
Luis Felipe Strano Moraes!
llvm-svn: 129558
|
|
|
|
| |
llvm-svn: 129503
|
|
|
|
|
|
| |
where the RHS is of the legal type for the new operation.
llvm-svn: 129484
|
|
|
|
|
|
| |
rdar://8911343
llvm-svn: 128696
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
multiplied value by introducing an early shift.
This allows us to compile "unsigned foo(unsigned x) { return x/28; }" into
shrl $2, %edi
imulq $613566757, %rdi, %rax
shrq $32, %rax
ret
instead of
movl %edi, %eax
imulq $613566757, %rax, %rcx
shrq $32, %rcx
subl %ecx, %eax
shrl %eax
addl %ecx, %eax
shrl $4, %eax
on x86_64
llvm-svn: 127829
|
|
|
|
|
|
| |
the type of the LHS.
llvm-svn: 126518
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
have their low bits set to zero. This allows us to optimize
out explicit stack alignment code like in stack-align.ll:test4 when
it is redundant.
Doing this causes the code generator to start turning FI+cst into
FI|cst all over the place, which is general goodness (that is the
canonical form) except that various pieces of the code generator
don't handle OR aggressively. Fix this by introducing a new
SelectionDAG::isBaseWithConstantOffset predicate, and using it
in places that are looking for ADD(X,CST). The ARM backend in
particular was missing a lot of addressing mode folding opportunities
around OR.
llvm-svn: 125470
|
|
|
|
| |
llvm-svn: 123664
|
|
|
|
|
|
|
|
|
| |
This shaves off 4 popcounts from the hacked 186.crafty source.
This is enabled even when a native popcount instruction is available. The
combined code is one operation longer but it should be faster nevertheless.
llvm-svn: 123621
|
|
|
|
|
|
|
|
|
|
|
| |
There's an inherent tension in DAGCombine between assuming
that things will be put in canonical form, and the Depth
mechanism that disables transformations when recursion gets
too deep. It would not surprise me if there's a lot of little
bugs like this one waiting to be discovered. The mechanism
seems fragile and I'd suggest looking at it from a design viewpoint.
llvm-svn: 123191
|
|
|
|
|
|
|
| |
etc. takes an option OptSize. If OptSize is true, it would return
the inline limit for functions with attribute OptSize.
llvm-svn: 122952
|
|
|
|
| |
llvm-svn: 122193
|
|
|
|
|
|
|
|
| |
zextOrTrunc(), and APSInt methods extend(), extOrTrunc() and new method
trunc(), to be const and to return a new value instead of modifying the
object in place.
llvm-svn: 121120
|
|
|
|
|
|
| |
and use this to disable a specific optimization. Patch by Micah Villmow!
llvm-svn: 120435
|
|
|
|
| |
llvm-svn: 119990
|
|
|
|
|
|
| |
{i64, i64} from matching i128.
llvm-svn: 118465
|
|
|
|
|
|
| |
basic logic, added initial platform support.
llvm-svn: 117667
|
|
|
|
|
|
|
| |
types are no longer Legal on X86, we don't need it.
No functional change. 8499854.
llvm-svn: 116947
|
|
|
|
| |
llvm-svn: 114490
|
|
|
|
|
|
| |
getLoad overloads.
llvm-svn: 114443
|
|
|
|
| |
llvm-svn: 113771
|
|
|
|
| |
llvm-svn: 113766
|
|
|
|
| |
llvm-svn: 112104
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
expanding: e.g. <2 x float> -> <4 x float> instead of -> 2 floats. This
affects two places in the code: handling cross block values and handling
function return and arguments. Since vectors are already widened by
legalizetypes, this gives us much better code and unblocks x86-64 abi
and SPU abi work.
For example, this (which is a silly example of a cross-block value):
define <4 x float> @test2(<4 x float> %A) nounwind {
%B = shufflevector <4 x float> %A, <4 x float> undef, <2 x i32> <i32 0, i32 1>
%C = fadd <2 x float> %B, %B
br label %BB
BB:
%D = fadd <2 x float> %C, %C
%E = shufflevector <2 x float> %D, <2 x float> undef, <4 x i32> <i32 0, i32 1, i32 undef, i32 undef>
ret <4 x float> %E
}
Now compiles into:
_test2: ## @test2
## BB#0:
addps %xmm0, %xmm0
addps %xmm0, %xmm0
ret
previously it compiled into:
_test2: ## @test2
## BB#0:
addps %xmm0, %xmm0
pshufd $1, %xmm0, %xmm1
## kill: XMM0<def> XMM0<kill> XMM0<def>
insertps $0, %xmm0, %xmm0
insertps $16, %xmm1, %xmm0
addps %xmm0, %xmm0
ret
This implements rdar://8230384
llvm-svn: 112101
|
|
|
|
|
|
| |
ISD::AND case of TargetLowering::SimplifyDemandedBits.
llvm-svn: 110019
|
|
|
|
|
|
|
| |
check the range of the constant when optimizing a comparison between a
constant and a sign_extend_inreg node.
llvm-svn: 109854
|
|
|
|
| |
llvm-svn: 109265
|
|
|
|
|
|
| |
are not demanded. This often allows the anyext to be folded away.
llvm-svn: 109242
|
|
|
|
| |
llvm-svn: 108991
|
|
|
|
|
|
| |
its scalar floating point registers alias its vector registers.
llvm-svn: 108761
|
|
|
|
|
|
|
|
| |
for legal value types. A "representative" register class is the largest legal super-reg register class for a value type. e.g. On i386, GR32 is the rep register class for i8 / i16 / i32; on x86_64 it would be GR64.
This property will be used by the register pressure tracking instruction scheduler.
llvm-svn: 108735
|