This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.glisse@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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]