movw. That is we promote the destination operand to r16. So
%CH = TRUNC_R16_R8 %BP
is emitted as
movw %bp, %cx.
This is incorrect. If %cl is live, it would be clobbered.
Ideally we want to do the opposite, that is emitted it as
movb ??, %ch
But this is not possible since %bp does not have a r8 sub-register.
We are now defining a new register class R16_ which is a subclass of R16
containing only those 16-bit registers that have r8 sub-registers (i.e.
AX - DX). We isel the truncate to two instructions, a MOV16to16_ to copy the
value to the R16_ class, followed by a TRUNC_R16_R8.
Due to bug 770, the register colaescer is not going to coalesce between R16 and
R16_. That will be fixed later so we can eliminate the MOV16to16_. Right now, it
can only be eliminated if we are lucky that source and destination registers are
the same.
llvm-svn: 28164
that gets emitted as movl (for r32 to i16, i8) or a movw (for r16 to i8). And
if the destination gets allocated a subregister of the source operand, then
the instruction will not be emitted at all.
llvm-svn: 28119
vla are present in the function. This causes a crash when a leaf function
allocates space on the stack used to store / load with 128-bit SSE
instructions.
llvm-svn: 27698
proves to be worth 20% on Ptrdist/ks. Might be related to dependency
breaking support.
2. Added FsMOVAPSrr and FsMOVAPDrr as aliases to MOVAPSrr and MOVAPDrr. These
are used for FR32 / FR64 reg-to-reg copies.
3. Tell reg-allocator to generate MOVSSrm / MOVSDrm and MOVSSmr / MOVSDmr to
spill / restore FsMOVAPSrr and FsMOVAPDrr.
llvm-svn: 26241
transfer.
According to the Intel P4 Optimization Manual:
Moves that write a portion of a register can introduce unwanted
dependences. The movsd reg, reg instruction writes only the bottom
64 bits of a register, not to all 128 bits. This introduces a dependence on
the preceding instruction that produces the upper 64 bits (even if those
bits are not longer wanted). The dependence inhibits register renaming,
and thereby reduces parallelism.
Not to mention movaps is shorter than movss.
llvm-svn: 26226
* Added a pseudo instruction (for each target) that represent "return void".
This is a workaround for lack of optional flag operand (return void is not
lowered so it does not have a flag operand.)
llvm-svn: 24997
that were overloaded to work before and after the stackifier runs. With the
new clean world, it is possible to write patterns for these instructions: woo!
This also adds a few simple patterns here and there, though there are a lot
still missing. These should be easy to add though. :)
See the comments under "Floating Point Stack Support" for more details on
the new world order.
This patch as absolutely no effect on the generated code, woo!
llvm-svn: 24899
XMM registers. There are many known deficiencies and fixmes, which will be
addressed ASAP. The major benefit of this work is that it will allow the
LLVM register allocator to allocate FP registers across basic blocks.
The x86 backend will still default to x87 style FP. To enable this work,
you must pass -enable-sse-scalar-fp and either -sse2 or -sse3 to llc.
An example before and after would be for:
double foo(double *P) { double Sum = 0; int i; for (i = 0; i < 1000; ++i)
Sum += P[i]; return Sum; }
The inner loop looks like the following:
x87:
.LBB_foo_1: # no_exit
fldl (%esp)
faddl (%eax,%ecx,8)
fstpl (%esp)
incl %ecx
cmpl $1000, %ecx
#FP_REG_KILL
jne .LBB_foo_1 # no_exit
SSE2:
addsd (%eax,%ecx,8), %xmm0
incl %ecx
cmpl $1000, %ecx
#FP_REG_KILL
jne .LBB_foo_1 # no_exit
llvm-svn: 22340
adjustment. If so, we merge the adjustment into the existing one. This
allows us to generate:
caller2:
sub %ESP, 12
mov DWORD PTR [%ESP], 0
mov %EAX, 1234567890
mov %EDX, 0
call func2
add %ESP, 8
ret 4
intead of:
caller2:
sub %ESP, 12
mov DWORD PTR [%ESP], 0
mov %EAX, 1234567890
mov %EDX, 0
call func2
sub %ESP, 4
add %ESP, 12
ret 4
for X86/fast-cc-merge-stack-adj.ll
llvm-svn: 22038
Evan Cheng