8351016: RA support for EVEX to REX/REX2 demotion to optimize NDD instructions

[jatin-bhateja]

Draft PR for NDD demotion colour biasing.

Currently, while picking the colour for a DST during the Select phase, we pick the first available colour and may miss out on demotion opportunities. Instruction encoding size is reduced by 2 bytes with a REX2 demotion and 3 bytes with REX demotion. Thus, it's an effective code size-oriented optimisation.

if (operation is commutative) {
   Bias dst with src1 or src2
} else {
   Bias dst with src1
}

Original Opto assembly

New Opto assembly

Print Assembly showing EEVEX to REX demoted instruction.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8351016: RA support for EVEX to REX/REX2 demotion to optimize NDD instructions (Enhancement - P4)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/26283/head:pull/26283
$ git checkout pull/26283

Update a local copy of the PR:
$ git checkout pull/26283
$ git pull https://git.openjdk.org/jdk.git pull/26283/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 26283

View PR using the GUI difftool:
$ git pr show -t 26283

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/26283.diff

[bridgekeeper]

👋 Welcome back jbhateja! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[jatin-bhateja]

/keepalive

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[jatin-bhateja]

/label add hotspot-compiler-dev

[openjdk]

@jatin-bhateja The pull request is being re-evaluated and the inactivity timeout has been reset.

[openjdk]

@jatin-bhateja
The hotspot-compiler label was successfully added.

[merykitty]

This may also be applicable to non-APX instructions. For example, in the case of casting long to int, if the destination and the source are the same, then we do not need to emit any code. As a result, do you think it is better to mark operands in the ad file to preferably have the same register as the result?

[jatin-bhateja]

This may also be applicable to non-APX instructions. For example, in the case of casting long to int, if the destination and the source are the same, then we do not need to emit any code. As a result, do you think it is better to mark operands in the ad file to preferably have the same register as the result?

Yes, for now, I limited this to APX, but biasing the allocation of destination to non-interfering use(src) will enable instruction elision during assembling. Currently, while assigning a color(reg) to a live range, the allocator picks the first free aligned register.

do you think it is better to mark operands in the ad file to preferably have the same register as the result?

There are existing DF attributions like USE_DEF which can be used to add such a constraint, but for APX NDD, we do not wish to up-front constrain the source to be the same as the destination, as it defeats the purpose, and the allocator may end up emitting a copy before the NDD instruction to honour this constraint. The idea here is to only bias color selection for non-interfering live ranges to facilitate EEVEX to REX/REX2 demotions.