[LLVMdev] Legal action type for BUILD_VECTOR

Eli Friedman eli.friedman at gmail.com
Fri Sep 30 13:08:13 PDT 2011


On Fri, Sep 30, 2011 at 12:43 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> Hello,
>
> I'm working on extending the current PowerPC backend to handle a vector
> instruction set for floating-point operations (IBM's double-hummer
> instruction set used on the BG/P supercomputers). In this instruction
> set, each of the existing floating-point registers becomes the first of
> two vector elements. I am having trouble optimizing the BUILD_VECTOR
> operation for the case where I am building a v2f64 vector out of two
> operands. I tried writing this pattern as:
>
> def : Pat<(v2f64 (build_vector F8RC:$A, F8RC:$B)),
>          (FSMFP (INSERT_SUBREG (v2f64 (IMPLICIT_DEF)), F8RC:$A,
> sub_64),
>                 (INSERT_SUBREG (v2f64 (IMPLICIT_DEF)), F8RC:$B,
> sub_64))>;
>
> Where the FSMFP instruction copies the first vector element of the
> second operand to the second vector element of the first operand. In
> other words, if I already have one of the floating point numbers in a
> floating point register I want to leave it there, and then copy in the
> second floating-point number to the second slot.
>
> The problem that I am having seems to be that I can't match build_vector
> this way. When I try, I receive the following assertion:
> clang: LegalizeDAG.cpp:994:
> llvm::SDValue<unnamed>::SelectionDAGLegalize::LegalizeOp(llvm::SDValue):
> Assertion `0 && "This action is not supported yet!"' failed.
>
> So it seems that the corresponding case statement does not even handle
> TargetLowering::Legal? Can this be changed to do what I want? Otherwise,
> how should I work around this?

You could try just marking it Expand; I think the default expansion
will do the right thing if you've implemented VECTOR_SHUFFLE and
SCALAR_TO_VECTOR correctly.  Otherwise, mark it custom and lower it to
something appropriate.  Legalization does weird things to BUILD_VECTOR
at the moment; we do plan on fixing that at some point.

-Eli




More information about the llvm-dev mailing list