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