2007-12-08 20:16:06 +00:00
|
|
|
//===-- LegalizeTypes.h - Definition of the DAG Type Legalizer class ------===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
2007-12-29 20:36:04 +00:00
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
2007-12-08 20:16:06 +00:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file defines the DAGTypeLegalizer class. This is a private interface
|
|
|
|
// shared between the code that implements the SelectionDAG::LegalizeTypes
|
|
|
|
// method.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#ifndef SELECTIONDAG_LEGALIZETYPES_H
|
|
|
|
#define SELECTIONDAG_LEGALIZETYPES_H
|
|
|
|
|
|
|
|
#define DEBUG_TYPE "legalize-types"
|
|
|
|
#include "llvm/CodeGen/SelectionDAG.h"
|
|
|
|
#include "llvm/Target/TargetLowering.h"
|
|
|
|
#include "llvm/ADT/DenseMap.h"
|
|
|
|
#include "llvm/Support/Compiler.h"
|
|
|
|
#include "llvm/Support/Debug.h"
|
|
|
|
|
|
|
|
namespace llvm {
|
|
|
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
/// DAGTypeLegalizer - This takes an arbitrary SelectionDAG as input and
|
|
|
|
/// hacks on it until the target machine can handle it. This involves
|
|
|
|
/// eliminating value sizes the machine cannot handle (promoting small sizes to
|
|
|
|
/// large sizes or splitting up large values into small values) as well as
|
|
|
|
/// eliminating operations the machine cannot handle.
|
|
|
|
///
|
|
|
|
/// This code also does a small amount of optimization and recognition of idioms
|
|
|
|
/// as part of its processing. For example, if a target does not support a
|
|
|
|
/// 'setcc' instruction efficiently, but does support 'brcc' instruction, this
|
|
|
|
/// will attempt merge setcc and brc instructions into brcc's.
|
|
|
|
///
|
|
|
|
class VISIBILITY_HIDDEN DAGTypeLegalizer {
|
|
|
|
TargetLowering &TLI;
|
|
|
|
SelectionDAG &DAG;
|
2008-02-03 07:13:32 +00:00
|
|
|
public:
|
2007-12-08 20:16:06 +00:00
|
|
|
// NodeIDFlags - This pass uses the NodeID on the SDNodes to hold information
|
|
|
|
// about the state of the node. The enum has all the values.
|
|
|
|
enum NodeIDFlags {
|
|
|
|
/// ReadyToProcess - All operands have been processed, so this node is ready
|
|
|
|
/// to be handled.
|
|
|
|
ReadyToProcess = 0,
|
|
|
|
|
|
|
|
/// NewNode - This is a new node that was created in the process of
|
|
|
|
/// legalizing some other node.
|
|
|
|
NewNode = -1,
|
|
|
|
|
|
|
|
/// Processed - This is a node that has already been processed.
|
|
|
|
Processed = -2
|
|
|
|
|
|
|
|
// 1+ - This is a node which has this many unlegalized operands.
|
|
|
|
};
|
2008-02-03 07:13:32 +00:00
|
|
|
private:
|
2007-12-08 20:16:06 +00:00
|
|
|
enum LegalizeAction {
|
|
|
|
Legal, // The target natively supports this type.
|
|
|
|
Promote, // This type should be executed in a larger type.
|
LegalizeTypes support for EXTRACT_VECTOR_ELT. The
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)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@47672 91177308-0d34-0410-b5e6-96231b3b80d8
2008-02-27 13:34:40 +00:00
|
|
|
Expand, // This type should be split into two types of half the size.
|
|
|
|
Scalarize, // Replace this one-element vector type with its element type.
|
|
|
|
Split // This vector type should be split into smaller vectors.
|
2007-12-08 20:16:06 +00:00
|
|
|
};
|
LegalizeTypes support for EXTRACT_VECTOR_ELT. The
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)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@47672 91177308-0d34-0410-b5e6-96231b3b80d8
2008-02-27 13:34:40 +00:00
|
|
|
|
2007-12-08 20:16:06 +00:00
|
|
|
/// ValueTypeActions - This is a bitvector that contains two bits for each
|
|
|
|
/// simple value type, where the two bits correspond to the LegalizeAction
|
LegalizeTypes support for EXTRACT_VECTOR_ELT. The
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)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@47672 91177308-0d34-0410-b5e6-96231b3b80d8
2008-02-27 13:34:40 +00:00
|
|
|
/// enum from TargetLowering. This can be queried with "getTypeAction(VT)".
|
2007-12-08 20:16:06 +00:00
|
|
|
TargetLowering::ValueTypeActionImpl ValueTypeActions;
|
|
|
|
|
|
|
|
/// getTypeAction - Return how we should legalize values of this type, either
|
LegalizeTypes support for EXTRACT_VECTOR_ELT. The
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)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@47672 91177308-0d34-0410-b5e6-96231b3b80d8
2008-02-27 13:34:40 +00:00
|
|
|
/// it is already legal, or we need to promote it to a larger integer type, or
|
|
|
|
/// we need to expand it into multiple registers of a smaller integer type, or
|
|
|
|
/// we need to scalarize a one-element vector type into the element type, or
|
|
|
|
/// we need to split a vector type into smaller vector types.
|
2007-12-08 20:16:06 +00:00
|
|
|
LegalizeAction getTypeAction(MVT::ValueType VT) const {
|
LegalizeTypes support for EXTRACT_VECTOR_ELT. The
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)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@47672 91177308-0d34-0410-b5e6-96231b3b80d8
2008-02-27 13:34:40 +00:00
|
|
|
switch (ValueTypeActions.getTypeAction(VT)) {
|
|
|
|
default:
|
|
|
|
assert(false && "Unknown legalize action!");
|
|
|
|
case TargetLowering::Legal:
|
|
|
|
return Legal;
|
|
|
|
case TargetLowering::Promote:
|
|
|
|
return Promote;
|
|
|
|
case TargetLowering::Expand:
|
|
|
|
// Expand can mean 1) split integer in half 2) scalarize single-element
|
|
|
|
// vector 3) split vector in two.
|
|
|
|
if (!MVT::isVector(VT))
|
|
|
|
return Expand;
|
|
|
|
else if (MVT::getVectorNumElements(VT) == 1)
|
|
|
|
return Scalarize;
|
|
|
|
else
|
|
|
|
return Split;
|
|
|
|
}
|
2007-12-08 20:16:06 +00:00
|
|
|
}
|
LegalizeTypes support for EXTRACT_VECTOR_ELT. The
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)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@47672 91177308-0d34-0410-b5e6-96231b3b80d8
2008-02-27 13:34:40 +00:00
|
|
|
|
2007-12-08 20:16:06 +00:00
|
|
|
/// isTypeLegal - Return true if this type is legal on this target.
|
|
|
|
bool isTypeLegal(MVT::ValueType VT) const {
|
LegalizeTypes support for EXTRACT_VECTOR_ELT. The
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)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@47672 91177308-0d34-0410-b5e6-96231b3b80d8
2008-02-27 13:34:40 +00:00
|
|
|
return ValueTypeActions.getTypeAction(VT) == TargetLowering::Legal;
|
2007-12-08 20:16:06 +00:00
|
|
|
}
|
LegalizeTypes support for EXTRACT_VECTOR_ELT. The
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)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@47672 91177308-0d34-0410-b5e6-96231b3b80d8
2008-02-27 13:34:40 +00:00
|
|
|
|
2007-12-08 20:16:06 +00:00
|
|
|
/// PromotedNodes - For nodes that are below legal width, this map indicates
|
|
|
|
/// what promoted value to use.
|
|
|
|
DenseMap<SDOperand, SDOperand> PromotedNodes;
|
|
|
|
|
|
|
|
/// ExpandedNodes - For nodes that need to be expanded this map indicates
|
|
|
|
/// which operands are the expanded version of the input.
|
|
|
|
DenseMap<SDOperand, std::pair<SDOperand, SDOperand> > ExpandedNodes;
|
|
|
|
|
|
|
|
/// ScalarizedNodes - For nodes that are <1 x ty>, this map indicates the
|
|
|
|
/// scalar value of type 'ty' to use.
|
|
|
|
DenseMap<SDOperand, SDOperand> ScalarizedNodes;
|
2007-12-08 22:40:18 +00:00
|
|
|
|
|
|
|
/// SplitNodes - For nodes that need to be split this map indicates
|
|
|
|
/// which operands are the expanded version of the input.
|
|
|
|
DenseMap<SDOperand, std::pair<SDOperand, SDOperand> > SplitNodes;
|
2007-12-08 20:16:06 +00:00
|
|
|
|
|
|
|
/// ReplacedNodes - For nodes that have been replaced with another,
|
|
|
|
/// indicates the replacement node to use.
|
|
|
|
DenseMap<SDOperand, SDOperand> ReplacedNodes;
|
|
|
|
|
|
|
|
/// Worklist - This defines a worklist of nodes to process. In order to be
|
|
|
|
/// pushed onto this worklist, all operands of a node must have already been
|
|
|
|
/// processed.
|
|
|
|
SmallVector<SDNode*, 128> Worklist;
|
|
|
|
|
|
|
|
public:
|
|
|
|
explicit DAGTypeLegalizer(SelectionDAG &dag)
|
|
|
|
: TLI(dag.getTargetLoweringInfo()), DAG(dag),
|
|
|
|
ValueTypeActions(TLI.getValueTypeActions()) {
|
|
|
|
assert(MVT::LAST_VALUETYPE <= 32 &&
|
|
|
|
"Too many value types for ValueTypeActions to hold!");
|
|
|
|
}
|
|
|
|
|
|
|
|
void run();
|
|
|
|
|
2008-02-26 11:21:42 +00:00
|
|
|
/// ReanalyzeNode - Recompute the NodeID and correct processed operands
|
|
|
|
/// for the specified node, adding it to the worklist if ready.
|
|
|
|
void ReanalyzeNode(SDNode *N) {
|
2008-02-03 07:08:51 +00:00
|
|
|
N->setNodeId(NewNode);
|
2008-02-26 11:21:42 +00:00
|
|
|
AnalyzeNewNode(N);
|
2008-02-03 07:08:51 +00:00
|
|
|
}
|
2008-02-26 11:21:42 +00:00
|
|
|
|
2007-12-08 20:16:06 +00:00
|
|
|
private:
|
2008-02-26 11:21:42 +00:00
|
|
|
void AnalyzeNewNode(SDNode *&N);
|
|
|
|
|
2007-12-08 20:16:06 +00:00
|
|
|
void ReplaceValueWith(SDOperand From, SDOperand To);
|
|
|
|
void ReplaceNodeWith(SDNode *From, SDNode *To);
|
|
|
|
|
|
|
|
void RemapNode(SDOperand &N);
|
|
|
|
|
2007-12-08 21:59:32 +00:00
|
|
|
// Common routines.
|
|
|
|
SDOperand CreateStackStoreLoad(SDOperand Op, MVT::ValueType DestVT);
|
|
|
|
SDOperand HandleMemIntrinsic(SDNode *N);
|
|
|
|
void SplitOp(SDOperand Op, SDOperand &Lo, SDOperand &Hi);
|
|
|
|
|
|
|
|
//===--------------------------------------------------------------------===//
|
|
|
|
// Promotion Support: LegalizeTypesPromote.cpp
|
|
|
|
//===--------------------------------------------------------------------===//
|
|
|
|
|
2007-12-08 20:16:06 +00:00
|
|
|
SDOperand GetPromotedOp(SDOperand Op) {
|
|
|
|
SDOperand &PromotedOp = PromotedNodes[Op];
|
|
|
|
RemapNode(PromotedOp);
|
|
|
|
assert(PromotedOp.Val && "Operand wasn't promoted?");
|
|
|
|
return PromotedOp;
|
|
|
|
}
|
|
|
|
void SetPromotedOp(SDOperand Op, SDOperand Result);
|
2007-12-08 21:59:32 +00:00
|
|
|
|
2007-12-08 20:16:06 +00:00
|
|
|
/// GetPromotedZExtOp - Get a promoted operand and zero extend it to the final
|
|
|
|
/// size.
|
|
|
|
SDOperand GetPromotedZExtOp(SDOperand Op) {
|
|
|
|
MVT::ValueType OldVT = Op.getValueType();
|
|
|
|
Op = GetPromotedOp(Op);
|
|
|
|
return DAG.getZeroExtendInReg(Op, OldVT);
|
|
|
|
}
|
2007-12-08 21:59:32 +00:00
|
|
|
|
2007-12-08 20:16:06 +00:00
|
|
|
// Result Promotion.
|
|
|
|
void PromoteResult(SDNode *N, unsigned ResNo);
|
LegalizeTypes support for EXTRACT_VECTOR_ELT. The
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)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@47672 91177308-0d34-0410-b5e6-96231b3b80d8
2008-02-27 13:34:40 +00:00
|
|
|
SDOperand PromoteResult_BIT_CONVERT(SDNode *N);
|
2008-02-24 07:36:03 +00:00
|
|
|
SDOperand PromoteResult_BUILD_PAIR(SDNode *N);
|
2007-12-08 20:16:06 +00:00
|
|
|
SDOperand PromoteResult_Constant(SDNode *N);
|
2008-02-13 18:01:53 +00:00
|
|
|
SDOperand PromoteResult_CTLZ(SDNode *N);
|
|
|
|
SDOperand PromoteResult_CTPOP(SDNode *N);
|
|
|
|
SDOperand PromoteResult_CTTZ(SDNode *N);
|
LegalizeTypes support for EXTRACT_VECTOR_ELT. The
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)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@47672 91177308-0d34-0410-b5e6-96231b3b80d8
2008-02-27 13:34:40 +00:00
|
|
|
SDOperand PromoteResult_EXTRACT_VECTOR_ELT(SDNode *N);
|
2007-12-08 20:16:06 +00:00
|
|
|
SDOperand PromoteResult_FP_ROUND(SDNode *N);
|
|
|
|
SDOperand PromoteResult_FP_TO_XINT(SDNode *N);
|
2008-02-13 18:01:53 +00:00
|
|
|
SDOperand PromoteResult_INT_EXTEND(SDNode *N);
|
2007-12-08 20:16:06 +00:00
|
|
|
SDOperand PromoteResult_LOAD(LoadSDNode *N);
|
|
|
|
SDOperand PromoteResult_SDIV(SDNode *N);
|
2008-02-13 18:01:53 +00:00
|
|
|
SDOperand PromoteResult_SELECT (SDNode *N);
|
|
|
|
SDOperand PromoteResult_SELECT_CC(SDNode *N);
|
|
|
|
SDOperand PromoteResult_SETCC(SDNode *N);
|
2007-12-08 20:16:06 +00:00
|
|
|
SDOperand PromoteResult_SHL(SDNode *N);
|
2008-02-13 18:01:53 +00:00
|
|
|
SDOperand PromoteResult_SimpleIntBinOp(SDNode *N);
|
2007-12-08 20:16:06 +00:00
|
|
|
SDOperand PromoteResult_SRA(SDNode *N);
|
|
|
|
SDOperand PromoteResult_SRL(SDNode *N);
|
2008-02-13 18:01:53 +00:00
|
|
|
SDOperand PromoteResult_TRUNCATE(SDNode *N);
|
|
|
|
SDOperand PromoteResult_UDIV(SDNode *N);
|
|
|
|
SDOperand PromoteResult_UNDEF(SDNode *N);
|
|
|
|
|
2007-12-08 21:59:32 +00:00
|
|
|
// Operand Promotion.
|
|
|
|
bool PromoteOperand(SDNode *N, unsigned OperandNo);
|
|
|
|
SDOperand PromoteOperand_ANY_EXTEND(SDNode *N);
|
2008-02-24 07:36:03 +00:00
|
|
|
SDOperand PromoteOperand_BUILD_PAIR(SDNode *N);
|
2008-02-15 19:34:17 +00:00
|
|
|
SDOperand PromoteOperand_BR_CC(SDNode *N, unsigned OpNo);
|
|
|
|
SDOperand PromoteOperand_BRCOND(SDNode *N, unsigned OpNo);
|
2008-02-24 07:36:03 +00:00
|
|
|
SDOperand PromoteOperand_BUILD_VECTOR(SDNode *N);
|
2007-12-08 21:59:32 +00:00
|
|
|
SDOperand PromoteOperand_FP_EXTEND(SDNode *N);
|
|
|
|
SDOperand PromoteOperand_FP_ROUND(SDNode *N);
|
|
|
|
SDOperand PromoteOperand_INT_TO_FP(SDNode *N);
|
2008-02-27 10:18:23 +00:00
|
|
|
SDOperand PromoteOperand_INSERT_VECTOR_ELT(SDNode *N, unsigned OpNo);
|
2008-02-27 08:53:44 +00:00
|
|
|
SDOperand PromoteOperand_MEMBARRIER(SDNode *N);
|
2008-02-15 19:34:17 +00:00
|
|
|
SDOperand PromoteOperand_RET(SDNode *N, unsigned OpNo);
|
2007-12-08 21:59:32 +00:00
|
|
|
SDOperand PromoteOperand_SELECT(SDNode *N, unsigned OpNo);
|
|
|
|
SDOperand PromoteOperand_SETCC(SDNode *N, unsigned OpNo);
|
2008-02-15 19:34:17 +00:00
|
|
|
SDOperand PromoteOperand_SIGN_EXTEND(SDNode *N);
|
2007-12-08 21:59:32 +00:00
|
|
|
SDOperand PromoteOperand_STORE(StoreSDNode *N, unsigned OpNo);
|
2008-02-15 19:34:17 +00:00
|
|
|
SDOperand PromoteOperand_TRUNCATE(SDNode *N);
|
|
|
|
SDOperand PromoteOperand_ZERO_EXTEND(SDNode *N);
|
|
|
|
|
2007-12-08 21:59:32 +00:00
|
|
|
void PromoteSetCCOperands(SDOperand &LHS,SDOperand &RHS, ISD::CondCode Code);
|
|
|
|
|
|
|
|
//===--------------------------------------------------------------------===//
|
|
|
|
// Expansion Support: LegalizeTypesExpand.cpp
|
|
|
|
//===--------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
void GetExpandedOp(SDOperand Op, SDOperand &Lo, SDOperand &Hi);
|
|
|
|
void SetExpandedOp(SDOperand Op, SDOperand Lo, SDOperand Hi);
|
|
|
|
|
2007-12-08 20:16:06 +00:00
|
|
|
// Result Expansion.
|
|
|
|
void ExpandResult(SDNode *N, unsigned ResNo);
|
|
|
|
void ExpandResult_ANY_EXTEND (SDNode *N, SDOperand &Lo, SDOperand &Hi);
|
2008-02-10 10:08:52 +00:00
|
|
|
void ExpandResult_AssertZext (SDNode *N, SDOperand &Lo, SDOperand &Hi);
|
2007-12-08 20:16:06 +00:00
|
|
|
void ExpandResult_BIT_CONVERT(SDNode *N, SDOperand &Lo, SDOperand &Hi);
|
2008-02-13 18:01:53 +00:00
|
|
|
void ExpandResult_BUILD_PAIR (SDNode *N, SDOperand &Lo, SDOperand &Hi);
|
|
|
|
void ExpandResult_Constant (SDNode *N, SDOperand &Lo, SDOperand &Hi);
|
|
|
|
void ExpandResult_CTLZ (SDNode *N, SDOperand &Lo, SDOperand &Hi);
|
|
|
|
void ExpandResult_CTPOP (SDNode *N, SDOperand &Lo, SDOperand &Hi);
|
|
|
|
void ExpandResult_CTTZ (SDNode *N, SDOperand &Lo, SDOperand &Hi);
|
LegalizeTypes support for EXTRACT_VECTOR_ELT. The
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)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@47672 91177308-0d34-0410-b5e6-96231b3b80d8
2008-02-27 13:34:40 +00:00
|
|
|
void ExpandResult_EXTRACT_VECTOR_ELT(SDNode *N, SDOperand &Lo, SDOperand &Hi);
|
2007-12-08 20:16:06 +00:00
|
|
|
void ExpandResult_LOAD (LoadSDNode *N, SDOperand &Lo, SDOperand &Hi);
|
2008-02-13 18:01:53 +00:00
|
|
|
void ExpandResult_MERGE_VALUES(SDNode *N, SDOperand &Lo, SDOperand &Hi);
|
|
|
|
void ExpandResult_SIGN_EXTEND(SDNode *N, SDOperand &Lo, SDOperand &Hi);
|
|
|
|
void ExpandResult_SIGN_EXTEND_INREG(SDNode *N, SDOperand &Lo, SDOperand &Hi);
|
|
|
|
void ExpandResult_TRUNCATE (SDNode *N, SDOperand &Lo, SDOperand &Hi);
|
|
|
|
void ExpandResult_UNDEF (SDNode *N, SDOperand &Lo, SDOperand &Hi);
|
|
|
|
void ExpandResult_ZERO_EXTEND(SDNode *N, SDOperand &Lo, SDOperand &Hi);
|
2007-12-08 20:16:06 +00:00
|
|
|
|
|
|
|
void ExpandResult_Logical (SDNode *N, SDOperand &Lo, SDOperand &Hi);
|
|
|
|
void ExpandResult_BSWAP (SDNode *N, SDOperand &Lo, SDOperand &Hi);
|
|
|
|
void ExpandResult_ADDSUB (SDNode *N, SDOperand &Lo, SDOperand &Hi);
|
|
|
|
void ExpandResult_ADDSUBC (SDNode *N, SDOperand &Lo, SDOperand &Hi);
|
|
|
|
void ExpandResult_ADDSUBE (SDNode *N, SDOperand &Lo, SDOperand &Hi);
|
|
|
|
void ExpandResult_SELECT (SDNode *N, SDOperand &Lo, SDOperand &Hi);
|
|
|
|
void ExpandResult_SELECT_CC (SDNode *N, SDOperand &Lo, SDOperand &Hi);
|
|
|
|
void ExpandResult_MUL (SDNode *N, SDOperand &Lo, SDOperand &Hi);
|
|
|
|
void ExpandResult_Shift (SDNode *N, SDOperand &Lo, SDOperand &Hi);
|
|
|
|
|
|
|
|
void ExpandShiftByConstant(SDNode *N, unsigned Amt,
|
|
|
|
SDOperand &Lo, SDOperand &Hi);
|
|
|
|
bool ExpandShiftWithKnownAmountBit(SDNode *N, SDOperand &Lo, SDOperand &Hi);
|
|
|
|
|
|
|
|
// Operand Expansion.
|
|
|
|
bool ExpandOperand(SDNode *N, unsigned OperandNo);
|
|
|
|
SDOperand ExpandOperand_BIT_CONVERT(SDNode *N);
|
2008-02-16 10:29:26 +00:00
|
|
|
SDOperand ExpandOperand_BR_CC(SDNode *N);
|
2008-02-24 07:36:03 +00:00
|
|
|
SDOperand ExpandOperand_BUILD_VECTOR(SDNode *N);
|
2007-12-08 20:16:06 +00:00
|
|
|
SDOperand ExpandOperand_EXTRACT_ELEMENT(SDNode *N);
|
|
|
|
SDOperand ExpandOperand_SETCC(SDNode *N);
|
2008-02-16 10:29:26 +00:00
|
|
|
SDOperand ExpandOperand_SINT_TO_FP(SDOperand Source, MVT::ValueType DestTy);
|
2007-12-08 20:16:06 +00:00
|
|
|
SDOperand ExpandOperand_STORE(StoreSDNode *N, unsigned OpNo);
|
2008-02-16 10:29:26 +00:00
|
|
|
SDOperand ExpandOperand_TRUNCATE(SDNode *N);
|
|
|
|
SDOperand ExpandOperand_UINT_TO_FP(SDOperand Source, MVT::ValueType DestTy);
|
|
|
|
|
2007-12-08 20:16:06 +00:00
|
|
|
void ExpandSetCCOperands(SDOperand &NewLHS, SDOperand &NewRHS,
|
|
|
|
ISD::CondCode &CCCode);
|
|
|
|
|
2007-12-08 21:59:32 +00:00
|
|
|
//===--------------------------------------------------------------------===//
|
|
|
|
// Scalarization Support: LegalizeTypesScalarize.cpp
|
|
|
|
//===--------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
SDOperand GetScalarizedOp(SDOperand Op) {
|
|
|
|
SDOperand &ScalarOp = ScalarizedNodes[Op];
|
|
|
|
RemapNode(ScalarOp);
|
|
|
|
assert(ScalarOp.Val && "Operand wasn't scalarized?");
|
|
|
|
return ScalarOp;
|
|
|
|
}
|
|
|
|
void SetScalarizedOp(SDOperand Op, SDOperand Result);
|
|
|
|
|
|
|
|
// Result Vector Scalarization: <1 x ty> -> ty.
|
|
|
|
void ScalarizeResult(SDNode *N, unsigned OpNo);
|
|
|
|
SDOperand ScalarizeRes_BinOp(SDNode *N);
|
|
|
|
SDOperand ScalarizeRes_UnaryOp(SDNode *N);
|
2008-02-27 10:18:23 +00:00
|
|
|
|
2007-12-08 21:59:32 +00:00
|
|
|
SDOperand ScalarizeRes_BIT_CONVERT(SDNode *N);
|
2008-02-27 10:18:23 +00:00
|
|
|
SDOperand ScalarizeRes_FPOWI(SDNode *N);
|
|
|
|
SDOperand ScalarizeRes_INSERT_VECTOR_ELT(SDNode *N);
|
|
|
|
SDOperand ScalarizeRes_LOAD(LoadSDNode *N);
|
2007-12-08 21:59:32 +00:00
|
|
|
SDOperand ScalarizeRes_SELECT(SDNode *N);
|
2008-02-27 10:18:23 +00:00
|
|
|
SDOperand ScalarizeRes_UNDEF(SDNode *N);
|
|
|
|
SDOperand ScalarizeRes_VECTOR_SHUFFLE(SDNode *N);
|
|
|
|
|
2007-12-08 20:16:06 +00:00
|
|
|
// Operand Vector Scalarization: <1 x ty> -> ty.
|
|
|
|
bool ScalarizeOperand(SDNode *N, unsigned OpNo);
|
LegalizeTypes support for EXTRACT_VECTOR_ELT. The
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)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@47672 91177308-0d34-0410-b5e6-96231b3b80d8
2008-02-27 13:34:40 +00:00
|
|
|
SDOperand ScalarizeOp_BIT_CONVERT(SDNode *N);
|
2008-02-20 17:38:09 +00:00
|
|
|
SDOperand ScalarizeOp_EXTRACT_VECTOR_ELT(SDNode *N);
|
|
|
|
SDOperand ScalarizeOp_STORE(StoreSDNode *N, unsigned OpNo);
|
2007-12-08 20:16:06 +00:00
|
|
|
|
2007-12-08 22:37:41 +00:00
|
|
|
//===--------------------------------------------------------------------===//
|
|
|
|
// Vector Splitting Support: LegalizeTypesSplit.cpp
|
|
|
|
//===--------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
void GetSplitOp(SDOperand Op, SDOperand &Lo, SDOperand &Hi);
|
|
|
|
void SetSplitOp(SDOperand Op, SDOperand Lo, SDOperand Hi);
|
|
|
|
|
|
|
|
// Result Vector Splitting: <128 x ty> -> 2 x <64 x ty>.
|
|
|
|
void SplitResult(SDNode *N, unsigned OpNo);
|
2007-12-08 23:08:49 +00:00
|
|
|
|
|
|
|
void SplitRes_UNDEF(SDNode *N, SDOperand &Lo, SDOperand &Hi);
|
|
|
|
void SplitRes_LOAD(LoadSDNode *N, SDOperand &Lo, SDOperand &Hi);
|
2007-12-08 23:58:27 +00:00
|
|
|
void SplitRes_BUILD_PAIR(SDNode *N, SDOperand &Lo, SDOperand &Hi);
|
|
|
|
void SplitRes_INSERT_VECTOR_ELT(SDNode *N, SDOperand &Lo, SDOperand &Hi);
|
|
|
|
void SplitRes_VECTOR_SHUFFLE(SDNode *N, SDOperand &Lo, SDOperand &Hi);
|
|
|
|
|
|
|
|
void SplitRes_BUILD_VECTOR(SDNode *N, SDOperand &Lo, SDOperand &Hi);
|
|
|
|
void SplitRes_CONCAT_VECTORS(SDNode *N, SDOperand &Lo, SDOperand &Hi);
|
|
|
|
void SplitRes_BIT_CONVERT(SDNode *N, SDOperand &Lo, SDOperand &Hi);
|
|
|
|
void SplitRes_UnOp(SDNode *N, SDOperand &Lo, SDOperand &Hi);
|
2007-12-08 23:08:49 +00:00
|
|
|
void SplitRes_BinOp(SDNode *N, SDOperand &Lo, SDOperand &Hi);
|
2007-12-08 23:58:27 +00:00
|
|
|
void SplitRes_FPOWI(SDNode *N, SDOperand &Lo, SDOperand &Hi);
|
|
|
|
void SplitRes_SELECT(SDNode *N, SDOperand &Lo, SDOperand &Hi);
|
2007-12-08 22:37:41 +00:00
|
|
|
|
|
|
|
// Operand Vector Scalarization: <128 x ty> -> 2 x <64 x ty>.
|
|
|
|
bool SplitOperand(SDNode *N, unsigned OpNo);
|
2008-02-20 17:38:09 +00:00
|
|
|
|
LegalizeTypes support for EXTRACT_VECTOR_ELT. The
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)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@47672 91177308-0d34-0410-b5e6-96231b3b80d8
2008-02-27 13:34:40 +00:00
|
|
|
SDOperand SplitOp_BIT_CONVERT(SDNode *N);
|
2008-02-20 17:38:09 +00:00
|
|
|
SDOperand SplitOp_EXTRACT_SUBVECTOR(SDNode *N);
|
LegalizeTypes support for EXTRACT_VECTOR_ELT. The
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)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@47672 91177308-0d34-0410-b5e6-96231b3b80d8
2008-02-27 13:34:40 +00:00
|
|
|
SDOperand SplitOp_EXTRACT_VECTOR_ELT(SDNode *N);
|
2007-12-09 00:06:19 +00:00
|
|
|
SDOperand SplitOp_RET(SDNode *N, unsigned OpNo);
|
2008-02-20 17:38:09 +00:00
|
|
|
SDOperand SplitOp_STORE(StoreSDNode *N, unsigned OpNo);
|
2008-02-27 13:03:44 +00:00
|
|
|
SDOperand SplitOp_VECTOR_SHUFFLE(SDNode *N, unsigned OpNo);
|
2007-12-08 20:16:06 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
} // end namespace llvm.
|
|
|
|
|
|
|
|
#endif
|