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

Quan Anh Mai qamai at openjdk.org
Fri Oct 3 12:15:48 UTC 2025


On Sat, 20 Sep 2025 19:47:55 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> I can't approve this approach. I think blindly biasing the color of an operation to that of its input is too optimistic and will lead to numerous false-positive cases. It is better to have a more fine-grained selection using the script in the ad file. For example:
>> 
>>     instruct addI_rReg_ndd(rRegI dst, rRegI src1, rRegI src2, rFlagsReg cr)
>>     %{
>>       predicate(UseAPX);
>>       match(Set dst (AddI src1 src2));
>>       effect(KILL cr);
>>       bias(src1);
>>       flag(PD::Flag_sets_overflow_flag, PD::Flag_sets_sign_flag, PD::Flag_sets_zero_flag, PD::Flag_sets_carry_flag, PD::Flag_sets_parity_flag);
>> 
>>       format %{ "eaddl    $dst, $src1, $src2\t# int ndd" %}
>>       ins_encode %{
>>         __ eaddl($dst$$Register, $src1$$Register, $src2$$Register, false);
>>       %}
>>       ins_pipe(ialu_reg_reg);
>>     %}
>
>> I can't approve this approach. I think blindly biasing the color of an operation to that of its input is too optimistic and will lead to numerous false-positive cases. It is better to have a more fine-grained selection using the script in the ad file. For example:
>> 
>> ```
>> instruct addI_rReg_ndd(rRegI dst, rRegI src1, rRegI src2, rFlagsReg cr)
>> %{
>>   predicate(UseAPX);
>>   match(Set dst (AddI src1 src2));
>>   effect(KILL cr);
>>   bias(src1);
>>   flag(PD::Flag_sets_overflow_flag, PD::Flag_sets_sign_flag, PD::Flag_sets_zero_flag, PD::Flag_sets_carry_flag, PD::Flag_sets_parity_flag);
>> 
>>   format %{ "eaddl    $dst, $src1, $src2\t# int ndd" %}
>>   ins_encode %{
>>     __ eaddl($dst$$Register, $src1$$Register, $src2$$Register, false);
>>   %}
>>   ins_pipe(ialu_reg_reg);
>> %}
>> ```
> 
> Solution takes into consideration the live range overlaps, biasing is only enforced if source live range ends at its user instruciton, while picking the color we don't follow first color selection but give preference to the bias.  Second operand bias is only enabled for commutative operations.  Biaising is simply an allocation time hint to allocator used while color selection, and does not modify the infererence graph of LRG.  Our assembler now supports EEVEX to REX/REX2 demotion if dst matches to either first or second source operand for commutative operations. So we just don't intent to bias towards the first but second source also.  Also we dont bias destination if it has a bounded live range.

@jatin-bhateja The issue I see here is that you try biasing for all kinds of instructions, not just the NDD ones. As a result, numerous nodes are uselessly biased and can lead to regression.

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

PR Comment: https://git.openjdk.org/jdk/pull/26283#issuecomment-3365455818


More information about the hotspot-compiler-dev mailing list