This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 1/n, i386]: Merge SSE and AVX patterns using "enable" attribute.
- From: Uros Bizjak <ubizjak at gmail dot com>
- To: Kirill Yukhin <kirill dot yukhin at gmail dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 6 Apr 2011 18:47:34 +0200
- Subject: Re: [PATCH 1/n, i386]: Merge SSE and AVX patterns using "enable" attribute.
- References: <BANLkTikz_nW=bMk_qPuhJQ-tusr_3cCC2w@mail.gmail.com> <BANLkTiknkxtFzV1WmB6o9jvA3gY8Fh6vdg@mail.gmail.com>
On Wed, Apr 6, 2011 at 1:12 PM, Kirill Yukhin <kirill.yukhin@gmail.com> wrote:
> Nice patch. But I have two question:
> - What will be with future extensions? E.g. what if `avxXX` will appear, do
> you think that common parts with previous extentions should be shrinked in
> that way?
The patch in fact mixes two somehow orthogonal approaches:
- uses "enable" attribute to merge the same SSE and AVX patterns that
differ only in the number of operands.
- introduces conditional vector float modes.
So, if there is AVXv2 that adds another mode, this mode can be added
to VF mode iterator as a mode that depends on TARGET_AVX2. More
likely, there will be new three-operand instructions and these will be
added with TARGET_AVX2 insn constraint. If there are no corresponding
two-operand instructions, then "enabled" attribute won't come into
play.
> - Are you replaced with that fancy method all the insn? E.g. adds with
> saturation are not touched by the patch (and I believe can be shrinked as
> well):
I did say that "This patch changes i386.md, "Parallel floating point
arithmetic" and
"Parallel floating point comparisons" sections of sse.md." in the
original patch submission, didn't I ? ;)
I'm sure that in addition to saturated adds, there are plenty of other
opportunities for "enabled" attribute. These will be attacked in
further patches - btw - you are more than welcome to look for them in
the .md files; candidate patterns are prefixed with avx_ .
Uros.