On Thu, Jun 15, 2023 at 10:15 AM Jan Beulich <jbeul...@suse.com> wrote:
>
> On 15.06.2023 09:45, Hongtao Liu wrote:
> > On Thu, Jun 15, 2023 at 3:07 PM Uros Bizjak via Gcc-patches
> > <gcc-patches@gcc.gnu.org> wrote:
> >> On Thu, Jun 15, 2023 at 8:03 AM Jan Beulich via Gcc-patches
> >> <gcc-patches@gcc.gnu.org> wrote:
> >>> + case 3:
> >>> + return "%vmovddup\t{%1, %0|%0, %1}";
> >>> + case 4:
> >>> + return "movlhps\t%0, %0";
> >>> + default:
> >>> + gcc_unreachable ();
> >>> + }
> >>> +}
> >>> + [(set_attr "isa" "sse2_noavx,avx,avx512f,sse3,noavx")
> >>> + (set_attr "type" "sselog1,sselog1,ssemov,sselog1,ssemov")
> >>> + (set_attr "prefix" "orig,maybe_evex,evex,maybe_vex,orig")
> >>> + (set_attr "mode" "TI,TI,TI,DF,V4SF")
> > alternative 2 should be XImode when !TARGET_AVX512VL.
>
> This gives me a chance to actually raise a related question I stumbled
> across several times: Which operand does the mode attribute actually
> describe? I've seen places where it's the source, but I've also seen
> places where it's the destination. Because of this mix I wasn't really
> sure that getting this attribute entirely correct is actually
> necessary, and hence I hoped it would be okay to not further complicate
> the attribute here.
It should be the mode the insn is operating in. So, zero-extended
SImode add is still operating in SImode, even if its output is DImode,
and TARGET_MMX_WITH_SSE are V4SFmode, even if their operands are all
V2SFmode.
Uros.
