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

Refactor ExpandConstantFP so it can optimize load from constpool of types larger than f64 into extload from smaller types.

llvm-svn: 47883

llvm-svn: 47875

llvm-svn: 47872

- Cleaned up how the prologue-epilogue inserter loops over the instructions.
- Instead of restarting the processing of an instruction if we remove an
  implicit kill, just update the end iterator and make sure that the iterator
  isn't incremented.

llvm-svn: 47870

llvm-svn: 47869

llvm-svn: 47868

llvm-svn: 47867

llvm-svn: 47866

llvm-svn: 47864

marking both a super- and sub-register as "killed". This removes implicit uses
that are marked as "killed".

llvm-svn: 47862

registers.

llvm-svn: 47861

the register scavenger to process all of those new instructions instead of just
the last one inserted.

llvm-svn: 47860

llvm-svn: 47798

unaligned load/store code using them.  Per review
of unaligned load/store vector patch.

llvm-svn: 47782

llvm-svn: 47779

llvm-svn: 47765

that instruction as its "last use". This fixes PR1925.

llvm-svn: 47758

llvm-svn: 47755

No need for coalescer to update kills. Only copies are coalesced and those instructions will be deleted. Doh.

llvm-svn: 47749

llvm-svn: 47748

llvm-svn: 47746

which allows more of the surrounding arithmetic to be done with APInt
instead of uint64_t.

llvm-svn: 47745

an APInt into a uint64_t to call getConstant.

llvm-svn: 47742

llvm-svn: 47736

generic & x86 versions; change generic to follow x86
and improve comments.  Add PPC version (not right
for non-Darwin.)

llvm-svn: 47734

llvm-svn: 47722

llvm-svn: 47710

llvm-svn: 47708

llvm-svn: 47703

same size as an int type by doing a bitconvert of
load/store of the int type (same algorithm as floating point).
This makes them work for ppc Altivec.  There was some
code that purported to handle loads of (some) vectors
by splitting them into two smaller vectors, but getExtLoad
rejects subvector loads, so this could never have worked;
the patch removes it.

llvm-svn: 47696

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