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

[Jatin Bhateja]

On Tue, 18 Nov 2025 23:48:57 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Jatin Bhateja has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   Review comments resolutions
>
> src/hotspot/cpu/x86/x86.ad line 2648:
> 
>> 2646:   // can be demoted to REX/REX2 encodings. For commutative operations with register
>> 2647:   // operands, allocation of definition operand is biased towards both the operands.
>> 2648:   return (((mdef->flags() & Node::PD::Flag_ndd_demotable) != 0) &&
> 
> It is called either with ` oper_index == 1` or ` oper_index == 2`. Can you make it explicit that any other operand doesn't participate in register biasing? Also, I'd expand the check, so it becomes clear that 1st operand requires `Flag_ndd_demotable` and 2nd requires `Flag_ndd_demotable` + `Flag_ndd_commutative` set.

Flag_ndd_deomotable applies to any kind of NDD pattern which is a candidate of demotion, while Flag_ndd_commutative is only set over operand commutative operations.

One very interesting fact which needs to be highlighted here is that ADLC generates state checks for both the original operand ordering and its flipped variant,  e.g. for addI_rReg_rReg_mem pattern where first source operand is register and second one is memory, DFA generates two reduction rules addI_rReg_rReg_mem and addI_rReg_rReg_mem_0, latter one is the flipped one, existing scheme of NDD demotion is able to take care of both the cases, one constraint being that deomatable operand should not cover more than one ideal input edges which makes it a complex operand and any of its component register should not be shared with definition.

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

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