APX vs "length changing prefix"

[Jiang, Haochen]

> From: Jan Beulich <jbeulich@suse.com>
> Sent: Friday, September 4, 2026 4:40 PM
> 
> On 04.09.2026 10:17, Jiang, Haochen wrote:
> >> From: Jan Beulich <jbeulich@suse.com>
> >> Sent: Friday, September 4, 2026 3:16 PM
> >>
> >> Haochen,
> >>
> >> unfortunately the APX spec doesn't go into any performance related
> >> details, and the Optimization Reference Manual doesn't look to cover
> >> APX at all so far. Certain legacy encoded insns have decode suffer
> >> from operand size prefixes changing the size of immediates. Does the
> >> same apply to APX EVEX-encoded forms, with the immediate size being
> >> determined by the embedded prefix?
> >>
> >
> > Do you mean that if you meet something like:
> >
> > {nf} add 0x7b, %ecx
> >
> > You want to have a 66 prefix on it to become imm16?
> 
> Well, not exactly (in part because the insn above cannot be encoded
> with imm16). What I'm asking is whether e.g.
> 
> 	{nf} add 0x777, %cx

Yes, it will suffer penalty.

If you use a "default" OSIZE/ASIZE for a given mode+opcode, then there's no
penalty. If you override something which changes overall length, there's a
potential penalty.

Thx,
Haochen

> 
> is penalized over either of
> 
> 	{nf} add 0x777, %ecx
> 	{nf} add 0x777, %rcx
> 
> (the former having imm16, the latter two having imm32). And I assume
> that like for legacy encodings
> 
> 	{nf} add 0x77, %cl
> 
> is not. (Yet independently the non-ND 8- and 16-bit forms then would
> likely suffer a partial register access penalty.)
>