APX vs "length changing prefix"

[Jan Beulich]

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

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.)

Jan