RFR: JDK-8153837: AArch64: Handle special cases for MaxINode & MinINode [v2]
Dmitry Chuyko
dchuyko at openjdk.org
Tue Dec 20 11:25:49 UTC 2022
On Tue, 20 Dec 2022 02:07:23 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:
>>> It sounds more sense to me if the ideal can make sure the constant input is the right child like what you did in the last commit. So that we only need the first rule like other commutative ops.
>>
>> To achieve that we will have to change max(max[...]) and max(add[...]) optimizations. For example the latter likely will have to look into both inputs. I.e. if we order Max to the left and Con to the right, Add can appear at any side etc. - any fixed order for 2 of 3 means not guaranteed order for the third one.
>
> So how about doing the constant swap at the start of the `ideal`, before all other optimizations (i.e. `max(max[...])` and `max(add[...])`). I think it can also benefit other optimizations. E.g. for this optimization:
>
> MaxI1(MaxI2(a, b), c) ==> MaxI1(a, MaxI2(b, c))
>
> If "`b`" is a constant in `MaxI2(a, b)`, and `c` is a constant in `MaxI1(...)`, After the above optimization, `MaxI2(b, c)` can be constant folding into a constant, which is good. But without the constant swap, (i.e. `b` and `c` may not be a constant), the constant folding will be missed for some cases.
Other optimizations up in the tree look into already finished nodes. As I said above we can't always order all of three Min/Max, Add, Con so they will have to duplicate search patterns. I would prefer to order Con to the right and maybe Min/Max to the left as well, but that feels like a separate improvement, after that reverted rules can be easily excluded from generated code.
-------------
PR: https://git.openjdk.org/jdk/pull/11570
More information about the hotspot-compiler-dev
mailing list