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

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

On Mon, 3 Dec 2012, Uros Bizjak wrote:

> On Sun, Dec 2, 2012 at 1:30 PM, Marc Glisse <marc.glisse@inria.fr> wrote:
>
>>>> here is a patch. If it is accepted, I'll extend it to other vm patterns
>>>> (mul, div, min, max are likely candidates, but I need to check the doc).
>>>> It
>>>> passed bootstrap+testsuite on x86_64-linux.
>>>>
>>>>
>>>> 2012-12-01  Marc Glisse  <marc.glisse@inria.fr>
>>>>
>>>>         PR target/54855
>>>> gcc/
>>>>         * config/i386/sse.md (<sse>_vm<plusminus_insn><mode>3): Rewrite
>>>>         pattern.
>>>>         * config/i386/i386-builtin-types.def: New function types.
>>>>         * config/i386/i386.c (ix86_expand_args_builtin): Likewise.
>>>>         (bdesc_args) <__builtin_ia32_addss, __builtin_ia32_subss,
>>>>         __builtin_ia32_addsd, __builtin_ia32_subsd>: Change prototype.
>>>>         * config/i386/xmmintrin.h: Adapt to new builtin prototype.
>>>>         * config/i386/emmintrin.h: Likewise.
>>>>         * doc/extend.texi (X86 Built-in Functions): Document changed
>>>> prototype.
>>>>
>>>> testsuite/
>>>>         * gcc.target/i386/pr54855-1.c: New testcase.
>>>>         * gcc.target/i386/pr54855-2.c: New testcase.
>>>
>>>
>>> Yes, the approach looks correct to me, but I wonder why we have
>>> different representations for v4sf and v2df cases? I'd say that we
>>> should canonicalize patterns somewhere in the middle end (probably to
>>> vec_merge variant, as IMO vec_dup looks like degenerated vec_merge
>>> variant), otherwise we will have pattern explosion.
>>
>>
>> (I assume s/vec_dup/vec_concat/ above)
>
> Ah, yes.
>
> 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.

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

Thanks,

-- 
Marc Glisse