This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [i386] scalar ops that preserve the high part of a vector
- From: Uros Bizjak <ubizjak at gmail dot com>
- To: Marc Glisse <marc dot glisse at inria dot fr>
- Cc: gcc-patches at gcc dot gnu dot org, "H.J. Lu" <hjl dot tools at gmail dot com>
- Date: Sun, 2 Dec 2012 11:51:00 +0100
- Subject: Re: [i386] scalar ops that preserve the high part of a vector
- References: <alpine.DEB.2.02.1210131032460.9651@stedding.saclay.inria.fr> <CAFULd4YHdLF1ZyxrMG8MhRjo40f-EfAJZnDOEBc80pOGa4WNGQ@mail.gmail.com> <alpine.DEB.2.02.1210141057010.3752@laptop-mg.saclay.inria.fr> <alpine.DEB.2.02.1211301317160.3783@laptop-mg.saclay.inria.fr> <CAFULd4bVFbr1KC6FrjWOhEfmqEr_v2VuQMFjg4+TpTB681=HhA@mail.gmail.com> <alpine.DEB.2.02.1211302244290.3783@laptop-mg.saclay.inria.fr> <alpine.DEB.2.02.1212011800400.19206@stedding.saclay.inria.fr>
On Sat, Dec 1, 2012 at 6:27 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.
However, the patch is too late for 4.8, but definitely a wanted
generalization and fix of a (partially) wrong representation.
I have also CCd HJ for his opinion, since the patch touches published headers.
Thanks,
Uros.