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

Jatin Bhateja jbhateja at openjdk.org
Mon Oct 27 07:32:45 UTC 2025


On Fri, 24 Oct 2025 17:05:35 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments resolutions
>
> src/hotspot/share/opto/chaitin.cpp line 1693:
> 
>> 1691:           // then bias its color towards its input's def.
>> 1692:           if (lrin1 != 0 && lrg->_copy_bias == 0 && _ifg->test_edge_sq(lidx, lrin1) == 0) {
>> 1693:             lrg->_copy_bias = lrin1;
> 
> I believe biasing is a hint, so it will not attempt to assign the same colour if they interfere. In that case is it better if we don't care about interference here?

Hi @merykitty ,
Just above this check, we are checking for neighbour interference and eliminating the neighbours' register assignments from the register mask of the current def's live range; two nodes in the interference graph (IFG) interfere iff their live ranges overlap. Biasing is indeed an allocation hint, which is currently guarded by the non-infereference check. During actual register assignment later in the flow, there are two possible cases:- 

1) Bias LRG was part of IFG and was already assigned a register, in the simplification phase we remove the LO degree LRGs from the interference graph as they are guaranteed to get a color (register), this in turn reduces the degree of their neighbours and eventually some of them may become K colorable where K is the number of register,  anyways cutting the long story short, in this case we assign the bias color to definition if it belong to the subset of def register mask. 

2) Bias LRG was part of the yanked list, which gets populated during the simplification stage and holds all the LRG removed from the interference graph, this generally captures LO degree LRGs, in this case since the LRG is not part of IFG hence and is not assigned a register yet, but we still constrain the definition register mask with the bias register mask.

So, the additional guard check is strict and may be relaxed as it makes the second case non-reachable.

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

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


More information about the hotspot-compiler-dev mailing list