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
