https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126000
--- Comment #7 from Hongtao Liu <liuhongt at gcc dot gnu.org> ---
(In reply to Dipesh Sharma from comment #6)
> (In reply to Hongtao Liu from comment #3)
> > GAS handles the downward direction automatically and safely(EVEX -> VEX).
> > The upward direction — promoting VEX to EVEX for code size benefits in
> > specific sequences — requires explicit {evex} prefix annotation in GCC,
> > since the assembler lacks the global context needed to make that decision
> > correctly.
>
> I took a brief look at how VEX-to-EVEX promotion could work in GCC today.
> For GCC to emit {evex} safely, RTL's prefix attribute needs to say whether
> an instruction can be encoded with both VEX and EVEX. Right now that isn't
> always the case. Several patterns are still marked vex even though an
> equivalent EVEX encoding exists (for example, under AVX512VL), so GCC can't
> tell them apart from instructions that really are VEX-only.
>
> One possible approach:
>
> Update the prefix attribute (for example, to maybe_evex) on every pattern
> that can be promoted.
> At final emission, after register allocation and once the displacements are
> known, pick whichever encoding is shorter. That means emitting {evex} when
> the compressed disp8*N form beats VEX with disp32, and otherwise leaving the
> instruction as VEX.
We still need accurate TARGET_*** flags to control whether the {evex} prefix
can be inserted for maybe_evex instructions, since different instructions
require different feature combinations — some need AVX512DQ, some need
AVX512VL, some may need others. Relying solely on the prefix attribute(your
e.g. maybe_evex) may not be enough.(or your mean the new attribute for each
alternative will be set according to the real TARGET_*** needed, then it sounds
reasonable).
Also when there's already EVEX register used in the instruction, no {evex}
prefix is needed.
> Doing this at final emission means the decision is made with full
> information, and GAS still handles the downward direction as it does now.
> Instruction length computation would need to use the same check, so branch
> shortening stays consistent.
>
> I'd appreciate your thoughts on whether this direction seems reasonable, or
> whether you would prefer a different way to mark promotable instructions.
