https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126000

--- Comment #6 from Dipesh Sharma <dipesh.sharma at amd dot com> ---
(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.
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.
  • [Bug target/126000] [x86] Missed... dipesh.sharma at amd dot com via Gcc-bugs

Reply via email to