Re: [i386] scalar ops that preserve the high part of a vector

[Marc Glisse <marc.glisse@inria.fr>]

On Wed, 5 Dec 2012, Paolo Bonzini wrote:

> Il 05/12/2012 15:22, Marc Glisse ha scritto:
>> +
>> +	/* The x86 back-end uses VEC_CONCAT to set an element in a V2DF, but
>> +	   VEC_MERGE for scalar operations that preserve the other elements
>> +	   of a vector.  */
>> +	if (GET_CODE (trueop1) == VEC_SELECT
>> +	    && GET_MODE (XEXP (trueop1, 0)) == mode
>> +	    && XVECLEN (XEXP (trueop1, 1), 0) == 1
>> +	    && INTVAL (XVECEXP (XEXP (trueop1, 1), 0, 0)) == 1)
>> +	  {
>> +	    rtx newop0 = gen_rtx_fmt_e (VEC_DUPLICATE, mode, trueop0);
>> +	    rtx newop1 = XEXP (trueop1, 0);
>> +	    return gen_rtx_fmt_eee (VEC_MERGE, mode, newop0, newop1,
>> +				    const1_rtx);
>> +	  }
>
> So this changes this:
>
>   (vec_concat:M R1:N (vec_select:N V2:M [1]))
>
> to this
>
>   (vec_merge:M (vec_duplicate:M R1:N) V2:M [1])

Yes.

> I wonder if more patterns in i386.md should be canonicalized.
> Basically, the occurrences of gen_rtx_VEC_CONCAT should be changed to
> simplify_gen_binary, and the fallout fixed.
>
> Otherwise you have patterns that will not match if someone does generate
> the vec_concat via simplify_gen_binary.

I wondered about that but underestimated the issue. If we decide that the 
vec_merge pattern is the canonical one, we should probably start by making 
ix86_expand_vector_set and others generate it (instead of the vec_concat 
one), and the simplify-rtx patch actually becomes less useful (but not 
useless).

I don't know Uros' position, but re-reading this message:
http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00069.html
it seems like he was indeed suggesting this.

Note that my first choice was to have the vec_concat pattern in sse.md (I 
like the vec_concat pattern better, and since ix86_expand_vector_set has a 
special case to generate it instead of vec_merge for V2DF, someone must 
have agreed at some point), but Uros wants a single entry (using macros) 
for V4SF+V2DF, and hence a similar pattern.

The only simplification we currently have with VEC_MERGE is constant 
propagation. If we are going to produce it more often, we need to add a 
few optimizations, like looking through a vec_select of a vec_merge, or 
doing nothing when merging a vector with itself, etc.

-- 
Marc Glisse