RFR: 8323220: Reassociate loop invariants involved in Cmps and Add/Subs

Joshua Cao duke at openjdk.org
Thu Jan 11 20:10:59 UTC 2024


On Thu, 11 Jan 2024 17:41:53 GMT, Joshua Cao <duke at openjdk.org> wrote:

> // inv1 == (x + inv2) => ( inv1 - inv2 ) == x
> // inv1 == (x - inv2) => ( inv1 + inv2 ) == x
> // inv1 == (inv2 - x) => (-inv1 + inv2 ) == x
> 
> 
> For example,
> 
> 
> fn(inv1, inv2)
>   while(...)
>       x = foobar()
>       if inv1 == x + inv2
>            blackhole()
> 
> 
> We can transform this into
> 
> 
> fn(inv1, inv2)
>   t = inv1 - inv2
>   while(...)
>       x = foobar()
>       if t == x
>            blackhole()
> 
> 
> Here is an example: https://github.com/openjdk/jdk/blob/b78896b9aafcb15f453eaed6e154a5461581407b/src/java.base/share/classes/java/lang/invoke/LambdaFormEditor.java#L910. LHS `1` and RHS `pos` are both loop invariant
> 
> Passes tier1 locally on Linux machine. Passes GHA on my fork.

test/hotspot/jtreg/compiler/loopopts/InvariantCodeMotionReassociateCmp.java line 191:

> 189:     @Arguments({Argument.NUMBER_42, Argument.NUMBER_42})
> 190:     @IR(failOn = {IRNode.SUB_I})
> 191:     public void leDontReassociate(int inv1, int inv2) {

I added DontReassociate tests for `le`, `gt`, and `ge`. For `lt`, C2 generates a second `SUB_I` as part of other transformations.

IR matching for ADD/SUB is pretty hard in general. They commonly are created as part of other transformations. Any suggestions on how I can test this better is appreciated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17375#discussion_r1449334691


More information about the hotspot-compiler-dev mailing list