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

[Uros Bizjak <ubizjak@gmail.com>]

On Mon, Dec 3, 2012 at 4:34 PM, Marc Glisse <marc.glisse@inria.fr> wrote:

>> However, looking a bit more into the usage cases for these patterns,
>> they are only used through intrinsics with _m128 operands. While your
>> proposed patch makes these patterns more general (they can use 64bit
>> aligned memory), this is not their usual usage, and for their intended
>> usage, your proposed improvement complicates these patterns
>> unnecessarily. Following on these facts, I'd say that we leave these
>> special patters (since they serve their purpose well) and rather
>> introduce new patterns for "other" uses.
>
>
> You mean like in the original patch?
> http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01279.html
>
> (it only had the V2DF version, not the V4SF one)
>
> Funny how we switched sides, now I am the one who would rather have a single
> pattern instead of having one for the builtin and one for recog. It seems
> that once we add the new pattern, keeping the old one is a waste of
> maintenance time, and the few extra rtx from the slightly longer pattern for
> these seldomly used builtins should be negligible.

Yes,  I didn't notice at the time that the intention of existing
patterns was to implement intrinsics that exclusively use _m128
operands.

> But I don't mind, if that's the version you prefer, I'll update the patch.

Actually, both approaches have their benefits and drawbacks.
Specialized vec_merge patterns can be efficiently macroized, and
support builtins with _m128 operands in a simple and efficient way.
You are proposing patterns that do not macroize well (this is what was
learned from your last patch) and require breakup of existing
macroized patterns.

So, we are actually adding new functionality - operations on an array
of values. IMO, this warrants new patterns, but please find a way for
V2DF and V4SF to macroize in the same way.

Uros.