llvm-svn: 47687

llvm-svn: 47686

llvm-svn: 47676

approach taken is different to that in LegalizeDAG
when it is a question of expanding or promoting the
result type: for example, if extracting an i64 from
a <2 x i64>, when i64 needs expanding, it bitcasts
the vector to <4 x i32>, extracts the appropriate
two i32's, and uses those for the Lo and Hi parts.
Likewise, when extracting an i16 from a <4 x i16>,
and i16 needs promoting, it bitcasts the vector to
<2 x i32>, extracts the appropriate i32, twiddles
the bits if necessary, and uses that as the promoted
value.  This puts more pressure on bitcast legalization,
and I've added the appropriate cases.  They needed to
be added anyway since users can generate such bitcasts
too if they want to.  Also, when considering various
cases (Legal, Promote, Expand, Scalarize, Split) it is
a pain that expand can correspond to Expand, Scalarize
or Split, so I've changed the LegalizeTypes enum so it
lists those different cases - now Expand only means
splitting a scalar in two.
The code produced is the same as by LegalizeDAG for
all relevant testcases, except for
2007-10-31-extractelement-i64.ll, where the code seems
to have improved (see below; can an expert please tell
me if it is better or not).
Before < vs after >.

<       subl    $92, %esp
<       movaps  %xmm0, 64(%esp)
<       movaps  %xmm0, (%esp)
<       movl    4(%esp), %eax
<       movl    %eax, 28(%esp)
<       movl    (%esp), %eax
<       movl    %eax, 24(%esp)
<       movq    24(%esp), %mm0
<       movq    %mm0, 56(%esp)
---
>       subl    $44, %esp
>       movaps  %xmm0, 16(%esp)
>       pshufd  $1, %xmm0, %xmm1
>       movd    %xmm1, 4(%esp)
>       movd    %xmm0, (%esp)
>       movq    (%esp), %mm0
>       movq    %mm0, 8(%esp)

<       subl    $92, %esp
<       movaps  %xmm0, 64(%esp)
<       movaps  %xmm0, (%esp)
<       movl    12(%esp), %eax
<       movl    %eax, 28(%esp)
<       movl    8(%esp), %eax
<       movl    %eax, 24(%esp)
<       movq    24(%esp), %mm0
<       movq    %mm0, 56(%esp)
---
>       subl    $44, %esp
>       movaps  %xmm0, 16(%esp)
>       pshufd  $3, %xmm0, %xmm1
>       movd    %xmm1, 4(%esp)
>       movhlps %xmm0, %xmm0
>       movd    %xmm0, (%esp)
>       movq    (%esp), %mm0
>       movq    %mm0, 8(%esp)

<       subl    $92, %esp
<       movaps  %xmm0, 64(%esp)
---
>       subl    $44, %esp

<       movl    16(%esp), %eax
<       movl    %eax, 48(%esp)
<       movl    20(%esp), %eax
<       movl    %eax, 52(%esp)
<       movaps  %xmm0, (%esp)
<       movl    4(%esp), %eax
<       movl    %eax, 60(%esp)
<       movl    (%esp), %eax
<       movl    %eax, 56(%esp)
---
>       pshufd  $1, %xmm0, %xmm1
>       movd    %xmm1, 4(%esp)
>       movd    %xmm0, (%esp)
>       movd    %xmm1, 12(%esp)
>       movd    %xmm0, 8(%esp)

<       subl    $92, %esp
<       movaps  %xmm0, 64(%esp)
---
>       subl    $44, %esp

<       movl    24(%esp), %eax
<       movl    %eax, 48(%esp)
<       movl    28(%esp), %eax
<       movl    %eax, 52(%esp)
<       movaps  %xmm0, (%esp)
<       movl    12(%esp), %eax
<       movl    %eax, 60(%esp)
<       movl    8(%esp), %eax
<       movl    %eax, 56(%esp)
---
>       pshufd  $3, %xmm0, %xmm1
>       movd    %xmm1, 4(%esp)
>       movhlps %xmm0, %xmm0
>       movd    %xmm0, (%esp)
>       movd    %xmm1, 12(%esp)
>       movd    %xmm0, 8(%esp)

llvm-svn: 47672

operand of a VECTOR_SHUFFLE.  The mask is a
vector of constant integers.  The code in
LegalizeDAG doesn't bother to legalize the
mask, since it's basically just storage for
a bunch of constants, however LegalizeTypes
is more picky.  The problem is that there may
not exist any legal vector-of-integers type
with a legal element type, so it is impossible
to create a legal mask!  Unless of course you
cheat by creating a BUILD_VECTOR where the
operands have a different type to the element
type of the vector being built...  This is
pretty ugly but works - all relevant tests in
the testsuite pass, and produce the same
assembler with and without LegalizeTypes.

llvm-svn: 47670

llvm-svn: 47669

Don't track max alignment during stack object allocations since they can be deleted later. Let PEI compute it.

llvm-svn: 47668

llvm-svn: 47667

llvm-svn: 47663

llvm-svn: 47657

llvm-svn: 47656

ComputeMaskedBits to use the APInt form, and remove the
non-APInt form.

llvm-svn: 47654

Change several cases in SimplifyDemandedMask that don't ever do any
simplifying to reuse the logic in ComputeMaskedBits instead of
duplicating it.

llvm-svn: 47648

instead of init'ing it maximally to zeros on entry.  getFreePhysReg
is pretty hot and only a few elements are typically used.  This speeds
up linscan by 5% on 176.gcc.

llvm-svn: 47631

llvm-svn: 47629

would have been a Godsend here!

llvm-svn: 47625

llvm-svn: 47623

llvm-svn: 47612

also fixes cfrac, flops, and 175.vpr

llvm-svn: 47605

CodeGen/PowerPC/illegal-element-type.ll): suppose
a node X is processed, and processing maps it to
a node Y.  Then X continues to exist in the DAG,
but with no users.  While processing some other
node, a new node may be created that happens to
be equal to X, and thus X will be reused rather
than a truly new node.  This can cause X to
"magically reappear", and since it is in the
Processed state in will not be reprocessed, so
at the end of type legalization the illegal node
X can still be present.  The solution is to replace
X with Y whenever X gets resurrected like this.

llvm-svn: 47601

llvm-svn: 47598

vr1 = extract_subreg vr2, 3
...
vr3 = extract_subreg vr1, 2
The end result is vr3 is equal to vr2 with subidx 2.

llvm-svn: 47592

after legalize.  Just because a constant is legal (e.g. 0.0 in SSE) 
doesn't mean that its negated value is legal (-0.0).  We could make
this stronger by checking to see if the negated constant is actually
legal post negation, but it doesn't seem like a big deal.

llvm-svn: 47591

llvm-svn: 47587

llvm-svn: 47566

a SignBitIsZero function to simplify a common use case.

llvm-svn: 47561

All remat'ed loads cannot be folded into two-address code. Not just argument loads. This change doesn't really have any impact on codegen.

llvm-svn: 47557

result and operand types are legal.

llvm-svn: 47546

llvm-svn: 47545

out of illegal elements (BUILD_VECTOR).  Uses and beefs
up BUILD_PAIR, though it didn't really have to.  Like
most of LegalizeTypes, does not support soft-float.
This cures all "make check" vector building failures.

llvm-svn: 47537

%r3 on PPC) in their ASM files. However, it's hard for humans to read
during debugging. Adding a new field to the register data that lets you
specify a different name to be printed than the one that goes into the
ASM file -- %x3 instead of %r3, for instance.

llvm-svn: 47534

llvm-svn: 47529

If remating a machine instr with virtual register operand, make sure the vr is avaliable at all uses regardless of whether it would be folded.

llvm-svn: 47526

Recognize loads of arguments as re-materializable first. Therefore if isReallyTriviallyReMaterializable() returns true it doesn't confuse it as a "normal" re-materializable instruction.

llvm-svn: 47520

llvm-svn: 47507

llvm-svn: 47500

Really really bad local register allocator bug. On X86, it was never using ESI, EDI, and EBP because of a bug in RALocal::isPhysRegAvailable(). For example, when
it checks if ESI is available, it then looks at registers aliases to ESI. SIL is marked -2 (not allocatable) but isPhysRegAvailable() incorrectly assumes it is in use and returns false for ESI.

llvm-svn: 47499

llvm-svn: 47496

llvm-svn: 47492

the way through.  It is now used for codegen.

llvm-svn: 47484