RFR: 8351016: RA support for EVEX to REX/REX2 demotion to optimize NDD instructions [v13]

Daniel Lundén dlunden at openjdk.org
Fri Nov 21 08:35:39 UTC 2025


On Thu, 20 Nov 2025 21:30:21 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> src/hotspot/cpu/x86/x86.ad line 2649:
>> 
>>> 2647:   }
>>> 2648: 
>>> 2649:   // First operand of MachNode corresponding to Intel APX NDD selection
>> 
>> Very informative comments! Thank you.
>> 
>> I suggest to shape it as follows:
>> 
>> if ((mdef->flags() & Node::PD::Flag_ndd_demotable) != 0) {
>>   switch (oper_index) {
>>     // First operand of MachNode corresponding to Intel APX NDD selection
>>     // pattern can share its assigned register with definition operand if
>>     // their live ranges do not overlap, in such a scenario we can demote
>>     // it to legacy map0/map1 instruction by replacing its 4-byte extended
>>     // EVEX prefix with shorter REX/REX2 encoding. Demotion candidates
>>     // are decorated with a special flag by instruction selector.
>>     case 1: return true;
>> 
>>     // For commutative operation allocation of definition
>>     // operand can also be biased towards second operand.
>>     case 2: return (mdef->flags() & Node::PD::Flag_ndd_commutative) != 0);
>> 
>>     // No register biasing supported for other operands.
>>     default: return false;
>>   }
>> }
>
> Speaking of implicit invariants, `Node::PD::Flag_ndd_commutative` implies `Node::PD::Flag_ndd_demotable` is also set. Please, add an assert to catch missing `Node::PD::Flag_ndd_demotable` flag.
> 
> Another constraint to assert: `mdef->operand_num_edges(oper_index) == 1` should be true for 1st operand when `Node::PD::Flag_ndd_demotable` is set and, also, for 2nd operand when `Node::PD::Flag_ndd_commutative` is set.
> 
> Also, any operand ordering constraints in AD instruction declaration? Is it possible to mess the order of declarations, so register biasing candidate operands don't occur as 1st and 2nd operands?

Two nits:
- Comma splice: "overlap, in such a scenario" -> "overlap. In such a scenario"
- "For commutative operation allocation of definition operand can also be biased towards second operand" reads a bit strange to me. Perhaps "Commutative operation allocations of definition operands can also be biased towards the second operand"?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26283#discussion_r2548946958


More information about the hotspot-compiler-dev mailing list