scalar vector shift expansion problem on 64-bit

David Miller davem@davemloft.net
Fri Oct 28 07:48:00 GMT 2011


I'm getting an ICE on 64-bit sparc for some vector test cases but
I'm not sure where the fix belongs.

When the compiler expands a vecor shift by scalar into a vector
shift by a vector it uses expand_vector_broadcast(), which has
a comment which states:

"The mode of OP must be the element mode of VMODE."

But no such guarentee exists, and during the compilation of
gcc.dg/vect/pr33953.c we end up trying to expand a broadcast where the
vector mode is V2SI and the scalar object is of type DImode.

The tree node for the shift count that gets expanded by
expand_normal() into this DImode rtx looks like:

 <ssa_name 0xf7269800
    type <integer_type 0xf71e63c0 int public SI
        size <integer_cst 0xf71ce960 constant 32>
        unit size <integer_cst 0xf71ce980 constant 4>
        align 32 symtab 0 alias set 2 canonical type 0xf71e63c0 precision 32 min <integer_cst 0xf71ce90\
0 -2147483648> max <integer_cst 0xf71ce920 2147483647>
        pointer_to_this <pointer_type 0xf71e6ae0>>
    visited var <parm_decl 0xf7270210 srcshift>def_stmt GIMPLE_NOP

    version 12>

Anyways, in the sparc backend I made use of the invariant
expand_vector_broadcast() mentions, and assumed that the vector
inner mode equals the mode of the RTX object being broadcast.

This results in a crash because I end up making a emit_move_insn()
call where the modes don't match up.

So should expand_vector_broadcast() really provide this invariant to
the vec_init expander, or does the vec_init expander need to tidy
things up with gen_lowpart() etc. calls?



More information about the Gcc mailing list