| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 48221
|
|
|
|
|
|
| |
around the def's and use's of the interval being allocated to make it possible for the interval to target a register and spill it right away and restore a register for uses. This likely generates terrible code but is before than aborting.
llvm-svn: 48218
|
|
|
|
|
|
| |
enhancements.
llvm-svn: 48215
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
into:
_test:
fldz
ret
instead of:
_test:
subl $12, %esp
#IMPLICIT_DEF %xmm0
movsd %xmm0, (%esp)
fldl (%esp)
addl $12, %esp
ret
llvm-svn: 48213
|
|
|
|
| |
llvm-svn: 48208
|
|
|
|
|
|
|
|
| |
and it's the result that requires expansion. This code is a little confusing
because the TargetLoweringInfo tables for [US]INT_TO_FP use the operand type
(the integer type) rather than the result type.
llvm-svn: 48206
|
|
|
|
|
|
| |
verify the register constraint matches what the instruction expects.
llvm-svn: 48205
|
|
|
|
| |
llvm-svn: 48204
|
|
|
|
| |
llvm-svn: 48201
|
|
|
|
| |
llvm-svn: 48196
|
|
|
|
| |
llvm-svn: 48194
|
|
|
|
| |
llvm-svn: 48189
|
|
|
|
| |
llvm-svn: 48175
|
|
|
|
|
|
|
| |
zero extension when checking if an unsigned multiply is
safe.
llvm-svn: 48171
|
|
|
|
| |
llvm-svn: 48170
|
|
|
|
| |
llvm-svn: 48169
|
|
|
|
| |
llvm-svn: 48167
|
|
|
|
|
|
|
|
| |
return ValueType can depend its operands' ValueType.
This is a cosmetic change, no functionality impacted.
llvm-svn: 48145
|
|
|
|
| |
llvm-svn: 48142
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the source is defined; BLR is the live range which is defined by the copy.
If ALR and BLR overlaps and end of BLR extends beyond end of ALR, e.g.
A = or A, B
...
B = A
...
C = A<kill>
...
= B
then do not add kills of A to the newly created B interval.
- Also fix some kill info update bug.
llvm-svn: 48141
|
|
|
|
| |
llvm-svn: 48140
|
|
|
|
|
|
| |
things happier down the road.
llvm-svn: 48138
|
|
|
|
|
|
| |
(e.g. v8i16 on x86) after legalizer. Instruction selection does not expect to see them. In all likelihood this can only be an issue in a bugpoint reduced test case.
llvm-svn: 48136
|
|
|
|
|
|
|
| |
Change insert/extract subreg instructions to be able to be used in TableGen patterns.
Use the above features to reimplement an x86-64 pseudo instruction as a pattern.
llvm-svn: 48130
|
|
|
|
|
|
|
|
|
|
| |
field to 32 bits, thus enabling correct handling of ByVal
structs bigger than 0x1ffff. Abstract interface a bit.
Fixes gcc.c-torture/execute/pr23135.c and
gcc.c-torture/execute/pr28982b.c in gcc testsuite (were ICE'ing
on ppc32, quietly producing wrong code on x86-32.)
llvm-svn: 48122
|
|
|
|
| |
llvm-svn: 48117
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
they are produced by calls (which are known exact) and by cross block copies
which are known to be produced by extends.
This improves:
define double @test2() {
%tmp85 = call double asm sideeffect "fld0", "={st(0)}"()
ret double %tmp85
}
from:
_test2:
subl $20, %esp
# InlineAsm Start
fld0
# InlineAsm End
fstpl 8(%esp)
movsd 8(%esp), %xmm0
movsd %xmm0, (%esp)
fldl (%esp)
addl $20, %esp
#FP_REG_KILL
ret
to:
_test2:
# InlineAsm Start
fld0
# InlineAsm End
#FP_REG_KILL
ret
by avoiding a f64 <-> f80 trip
llvm-svn: 48108
|
|
|
|
|
|
|
|
|
|
|
|
| |
an RFP register class.
Teach ScheduleDAG how to handle CopyToReg with different src/dst
reg classes.
This allows us to compile trivial inline asms that expect stuff
on the top of x87-fp stack.
llvm-svn: 48107
|
|
|
|
|
|
|
|
| |
in different register classes, e.g. copy of ST(0) to RFP*. This gets
some really trivial inline asm working that plops things on the top of
stack (PR879)
llvm-svn: 48105
|
|
|
|
| |
llvm-svn: 48100
|
|
|
|
| |
llvm-svn: 48097
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
of BUILD_VECTORS that only have two unique elements:
1. The previous code was nondeterminstic, because it walked a map in
SDOperand order, which isn't determinstic.
2. The previous code didn't handle the case when one element was undef
very well. Now we ensure that the generated shuffle mask has the
undef vector on the RHS (instead of potentially being on the LHS)
and that any elements that refer to it are themselves undef. This
allows us to compile CodeGen/X86/vec_set-9.ll into:
_test3:
movd %rdi, %xmm0
punpcklqdq %xmm0, %xmm0
ret
instead of:
_test3:
movd %rdi, %xmm1
#IMPLICIT_DEF %xmm0
punpcklqdq %xmm1, %xmm0
ret
... saving a register.
llvm-svn: 48060
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
_test3:
movd %rdi, %xmm1
#IMPLICIT_DEF %xmm0
punpcklqdq %xmm1, %xmm0
ret
instead of:
_test3:
#IMPLICIT_DEF %rax
movd %rax, %xmm0
movd %rdi, %xmm1
punpcklqdq %xmm1, %xmm0
ret
This is still not ideal. There is no reason to two xmm regs.
llvm-svn: 48058
|
|
|
|
|
|
| |
and prefetchnta instructions.
llvm-svn: 48042
|
|
|
|
|
|
| |
kills the sub-register.
llvm-svn: 48038
|
|
|
|
|
|
| |
register, there must be an implicit def of the super-register on the MI.
llvm-svn: 48024
|
|
|
|
|
|
|
|
| |
%r3<def> = OR %x3<kill>, %x3
We don't want to mark the %r3 as unused even though it's a sub-register of %x3.
llvm-svn: 48003
|
|
|
|
| |
llvm-svn: 47998
|
|
|
|
| |
llvm-svn: 47996
|
|
|
|
| |
llvm-svn: 47992
|
|
|
|
| |
llvm-svn: 47966
|
|
|
|
|
|
| |
and add some protection against creating such.
llvm-svn: 47957
|
|
|
|
|
|
|
|
| |
except ppc long double. This allows us to shrink constant pool
entries for x86 long double constants, which in turn allows us to
use flds/fldl instead of fldt.
llvm-svn: 47938
|
|
|
|
|
|
|
|
| |
constant
all the way to float, not stopping at double.
llvm-svn: 47937
|
|
|
|
|
|
|
|
| |
bug in r47928 (Int64Ty is the correct type for the constant
pool entry here) and removes the asserts, now that the code
is capable of handling i128.
llvm-svn: 47932
|
|
|
|
|
|
|
|
| |
constant.
For x86, if sse2 is available, it's not a good idea since cvtss2sd is slower than a movsd load and it prevents load folding. On x87, it's important to shrink fp constant since fldt is very expensive.
llvm-svn: 47931
|
|
|
|
| |
llvm-svn: 47929
|
|
|
|
| |
llvm-svn: 47928
|
|
|
|
|
|
| |
findRegisterUseOperandIdx, findRegisterDefOperandIndx. Fix some naming inconsistencies.
llvm-svn: 47927
|
|
|
|
|
|
|
| |
The basic idea is that all these algorithms are computing the longest paths from the root node or to the exit node. Therefore the existing implementation that uses and iterative and potentially
exponential algorithm was changed to a well-known graph algorithm based on dynamic programming. It has a linear run-time.
llvm-svn: 47884
|