On Wed, Apr 6, 2011 at 1:12 PM, Kirill Yukhin <kirill.yuk...@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.