| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
more work).
llvm-svn: 28044
|
| |
|
|
|
|
|
|
|
| |
instructions in the virtregfolded map that were deleted. Because they
were deleted, newly allocated instructions could end up at the same address,
magically finding themselves in the map. The solution is to remove entries
from the map when we delete the instructions.
llvm-svn: 28041
|
| |
|
|
|
|
|
| |
instruction folded with spill code, make sure the remove the load from
the virt reg folded map.
llvm-svn: 28040
|
| |
|
|
| |
llvm-svn: 28039
|
| |
|
|
| |
llvm-svn: 28035
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
up the schedule. This helps code that looks like this:
loads ...
computations (first set) ...
stores (first set) ...
loads
computations (seccond set) ...
stores (seccond set) ...
Without this change, the stores and computations are more likely to
interleave:
loads ...
loads ...
computations (first set) ...
computations (second set) ...
computations (first set) ...
stores (first set) ...
computations (second set) ...
stores (stores set) ...
This can increase the number of spills if we are unlucky.
llvm-svn: 28033
|
| |
|
|
| |
llvm-svn: 28030
|
| |
|
|
|
|
| |
performance regressions.
llvm-svn: 28029
|
| |
|
|
| |
llvm-svn: 28026
|
| |
|
|
|
|
|
|
| |
But this is incorrect if the spilled value live range extends beyond the
current BB.
It is currently controlled by a temporary option -spiller-check-liveout.
llvm-svn: 28024
|
| |
|
|
|
|
|
|
| |
SingleSource/UnitTests/2006-01-23-InitializedBitField.c
with some changes I have to the new CFE.
llvm-svn: 28022
|
| |
|
|
| |
llvm-svn: 28012
|
| |
|
|
|
|
| |
FORMAL_ARGUMENTS SDOperand in the return result vector.
llvm-svn: 28009
|
| |
|
|
|
|
| |
the same. In this case, don't emit a noop copy.
llvm-svn: 28008
|
| |
|
|
|
|
| |
node can be folded.
llvm-svn: 28003
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and is already available, instead of falling back to emitting a load, fall
back to emitting a reg-reg copy. This generates significantly better code
for some SSE testcases, as SSE has lots of two-address instructions and
none of them are read/modify/write. As one example, this change does:
pshufd %XMM5, XMMWORD PTR [%ESP + 84], 255
xorps %XMM2, %XMM5
cmpltps %XMM1, %XMM0
- movaps XMMWORD PTR [%ESP + 52], %XMM0
- movapd %XMM6, XMMWORD PTR [%ESP + 52]
+ movaps %XMM6, %XMM0
cmpltps %XMM6, XMMWORD PTR [%ESP + 68]
movapd XMMWORD PTR [%ESP + 52], %XMM6
movaps %XMM6, %XMM0
cmpltps %XMM6, XMMWORD PTR [%ESP + 36]
cmpltps %XMM3, %XMM0
- movaps XMMWORD PTR [%ESP + 20], %XMM0
- movapd %XMM7, XMMWORD PTR [%ESP + 20]
+ movaps %XMM7, %XMM0
cmpltps %XMM7, XMMWORD PTR [%ESP + 4]
movapd XMMWORD PTR [%ESP + 20], %XMM7
cmpltps %XMM4, %XMM0
... which is far better than a store followed by a load!
llvm-svn: 28001
|
| |
|
|
|
|
| |
(VAND, VADD, etc.). Legalizer will assert otherwise.
llvm-svn: 27991
|
| |
|
|
|
|
| |
PR748.
llvm-svn: 27987
|
| |
|
|
| |
llvm-svn: 27974
|
| |
|
|
|
|
|
| |
the jump table's range check block. This re-enables 100% dense jump tables
by default on PPC & x86
llvm-svn: 27952
|
| |
|
|
|
|
| |
these.
llvm-svn: 27950
|
| |
|
|
|
|
| |
updating the machine CFG.
llvm-svn: 27949
|
| |
|
|
|
|
|
|
| |
x86 and ppc for 100% dense switch statements when relocations are non-PIC.
This support will be extended and enhanced in the coming days to support
PIC, and less dense forms of jump tables.
llvm-svn: 27947
|
| |
|
|
|
|
| |
miscompares). Switch RISC targets to use the list-td scheduler, which isn't.
llvm-svn: 27933
|
| |
|
|
| |
llvm-svn: 27930
|
| |
|
|
|
|
|
|
|
| |
llvm-gcc4 boostrap. Whenever a node is deleted by the dag combiner, it
*must* be returned by the visit function, or the dag combiner will not
know that the node has been processed (and will, e.g., send it to the
target dag combine xforms).
llvm-svn: 27922
|
| |
|
|
| |
llvm-svn: 27899
|
| |
|
|
| |
llvm-svn: 27893
|
| |
|
|
|
|
|
|
| |
DAG combiner can turn a VAND V, <-1, 0, -1, -1>, i.e. vector clear elements,
into a vector shuffle with a zero vector. It only does so when TLI tells it
the xform is profitable.
llvm-svn: 27874
|
| |
|
|
| |
llvm-svn: 27863
|
| |
|
|
| |
llvm-svn: 27846
|
| |
|
|
|
|
| |
the code in GCC PR26546.
llvm-svn: 27780
|
| |
|
|
| |
llvm-svn: 27775
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and a shuffle. For this:
void %test2(<4 x float>* %F, float %f) {
%tmp = load <4 x float>* %F ; <<4 x float>> [#uses=2]
%tmp3 = add <4 x float> %tmp, %tmp ; <<4 x float>> [#uses=1]
%tmp2 = insertelement <4 x float> %tmp3, float %f, uint 2 ; <<4 x float>> [#uses=2]
%tmp6 = add <4 x float> %tmp2, %tmp2 ; <<4 x float>> [#uses=1]
store <4 x float> %tmp6, <4 x float>* %F
ret void
}
we now get this on X86 (which will get better):
_test2:
movl 4(%esp), %eax
movaps (%eax), %xmm0
addps %xmm0, %xmm0
movaps %xmm0, %xmm1
shufps $3, %xmm1, %xmm1
movaps %xmm0, %xmm2
shufps $1, %xmm2, %xmm2
unpcklps %xmm1, %xmm2
movss 8(%esp), %xmm1
unpcklps %xmm1, %xmm0
unpcklps %xmm2, %xmm0
addps %xmm0, %xmm0
movaps %xmm0, (%eax)
ret
instead of:
_test2:
subl $28, %esp
movl 32(%esp), %eax
movaps (%eax), %xmm0
addps %xmm0, %xmm0
movaps %xmm0, (%esp)
movss 36(%esp), %xmm0
movss %xmm0, 8(%esp)
movaps (%esp), %xmm0
addps %xmm0, %xmm0
movaps %xmm0, (%eax)
addl $28, %esp
ret
llvm-svn: 27765
|
| |
|
|
|
|
| |
to write one pattern for vector stores instead of 4.
llvm-svn: 27730
|
| |
|
|
|
|
| |
buildvectors.
llvm-svn: 27723
|
| |
|
|
| |
llvm-svn: 27695
|
| |
|
|
|
|
| |
about "dereferencing type-punned pointer will break strict-aliasing rules"
llvm-svn: 27671
|
| |
|
|
| |
llvm-svn: 27632
|
| |
|
|
| |
llvm-svn: 27606
|
| |
|
|
|
|
| |
shouldcustom legalize it and remove their XXXTargetLowering::LowerArguments overload
llvm-svn: 27604
|
| |
|
|
|
|
| |
getNode do it. This fixes CodeGen/Generic/2006-04-11-vecload.ll
llvm-svn: 27602
|
| |
|
|
| |
llvm-svn: 27586
|
| |
|
|
| |
llvm-svn: 27580
|
| |
|
|
| |
llvm-svn: 27578
|
| |
|
|
| |
llvm-svn: 27574
|
| |
|
|
| |
llvm-svn: 27559
|
| |
|
|
| |
llvm-svn: 27542
|
| |
|
|
|
|
| |
to match again :)
llvm-svn: 27533
|
| |
|
|
| |
llvm-svn: 27529
|