RFR: 8349582: APX NDD code generation for OpenJDK

[Jatin Bhateja]

On Thu, 6 Feb 2025 20:26:49 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

> The goal of this PR is to generate code using APX NDD instructions.

Some initial comments.

src/hotspot/cpu/x86/x86_64.ad line 1555:

> 1553:   } else {
> 1554:     return (offset < 0x80) ? 5 : 8; // REX
> 1555:   }

Please move this out to a separate patch.

src/hotspot/cpu/x86/x86_64.ad line 5804:

> 5802: %}
> 5803: 
> 5804: instruct countTrailingZerosL_mem_nf(rRegI dst, memory src, rFlagsReg cr) %{

Why are we using rflagsReg operand for Non-Flags affecting patterns?

src/hotspot/cpu/x86/x86_64.ad line 5809:

> 5807:   effect(KILL cr);
> 5808: 
> 5809:   ins_cost(175);

Could you please let me know why you're using ins_cost here and not in above pattern?

src/hotspot/cpu/x86/x86_64.ad line 7322:

> 7320:   ins_encode %{
> 7321:     __ eaddq($dst$$Register, $src1$$Register, $src2$$Register, false);
> 7322:   %}

Current scheme is favoring emission of NDD instruction on APX enabled targets, even if destination and source registers belongs legacy GPR set. We should extend assembler layer to demote EEVEX to REX encoding if dst matches with source operands.

FYI, processor backend also uses Move Elimination to prevent dispatch of  GPR to GPR moves to execution ports.

This can be used to further break NDD pattens with all different legacy register operands, GPR to GPR moves should consume no more than 3 bytes encoding 1 byte for REX prefix, 1 for opcode and 1 for ModRM byte, still less than 4 byte prefix.

src/hotspot/cpu/x86/x86_64.ad line 7359:

> 7357:   effect(KILL cr);
> 7358: 
> 7359:   format %{ "eaddq    $dst, $src1, $src2\t# long ndd" %}

Can you kindly share the impact of adding all these new patterns on libjvm.so size ?

I am curious to know the amount of ADLC generated code for all these new patterns.

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

PR Review: https://git.openjdk.org/jdk/pull/23501#pullrequestreview-2601192411
PR Review Comment: https://git.openjdk.org/jdk/pull/23501#discussion_r1946208661
PR Review Comment: https://git.openjdk.org/jdk/pull/23501#discussion_r1946212191
PR Review Comment: https://git.openjdk.org/jdk/pull/23501#discussion_r1946216069
PR Review Comment: https://git.openjdk.org/jdk/pull/23501#discussion_r1946202682
PR Review Comment: https://git.openjdk.org/jdk/pull/23501#discussion_r1946203337