Thanks for the explanation! By the way, if we decide to have one pattern for V4SF instructions and another for V2DF, we could try to use recently introduced define_subst here. It won't reduce number of actual patterns (I mean number of patterns after iterators and subst expanding), but it could help to make sse.md more compact.
On 7 December 2012 12:49, Marc Glisse <marc.gli...@inria.fr> wrote: > On Fri, 7 Dec 2012, Michael Zolotukhin wrote: > >> 1) Does the root problem lay in the fact that even for scalar >> additions we perform the addition on the whole vector and only then >> drop the higher parts of the vector? I.e. to fix the test from the PR >> we need to replace plus on vector mode with plus on scalar mode? > > > The root problem is that we model the subs[sd] instructions as taking a > 128-bit second operand, when Intel's documentation says they take a > 32/64-bit operand, which is an important difference for memory operands (and > constants). Writing a pattern that reconstructs the result from a scalar > operation also seems more natural than pretending we are doing a parallel > operation and dropping most of it (easier for recog and friends). > > (note: I think the insn was written to support the intrinsic, which does > take a 128-bit argument, so it did a good job for that) > > >> 2) Is one of the main requirements having the same pattern for V4SF >> and V2DF version? > > > Uros seems to think that would be best. > > >> 3) I don't see vec_concat in patterns from your patches, is it >> explicitly generated by some x86-expander? > > > It is generated by ix86_expand_vector_set. > > >> Anyway, I really like the idea of having some uniformity in describing >> patterns for scalar instructions, so thank you for the work! > > > For 2-element vectors, vec_concat does seem more natural than vec_merge. If > we chose vec_merge as the canonical representation, we should chose it for > setting an element in a vector (ix86_expand_vector_set) everywhere, not just > those scalarish operations. > > So it would be good to have rth's opinion on this (svn blame seems to > indicate he is the one who chose to use vec_concat specifically for V2DF > instead of vec_merge). > > -- > Marc Glisse -- --- Best regards, Michael V. Zolotukhin, Software Engineer Intel Corporation.
