RFR: 8350988: Consolidate Identity of self-inverse operations

[Damon Fenacci]

On Sat, 1 Mar 2025 13:34:30 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

> subnode has multiple nodes that are self-inverse but lacking the respective optimization. ReverseINode and ReverseLNode already have the optimization, but we can deduplicate the code for all those operations.
> 
> For most nodes, the optimization is obvious. The NegF/DNodes however are worth to look at in detail imo:
> - `Float.NaN` has the same bits set as `-Float.NaN`. That means, it this specific case, the operation is a no-op anyway
> - For other values, the msb is flipped, flipping twice results in the original value again.
> 
> Similar changes could be made to the corresponding vector nodes. If you want, I can do that in a follow-up RFE.
> 
> One note: During benchmarking those changes, I ran into https://bugs.openjdk.org/browse/JDK-8307516. That means code like
> 
>         int v = 0;
>         for (int datum : data) {
>             v ^= Integer.reverseBytes(Integer.reverseBytes(datum));
>         }
>         return v;
> 
> was vectorized before but is considered "not profitable" with the changes here, causing slowdowns in such cases.

Nice refinement @SirYwell!
You are mentioning that

> During benchmarking those changes, I ran into https://bugs.openjdk.org/browse/JDK-8307516. That means code like
> 
>         int v = 0;
>         for (int datum : data) {
>             v ^= Integer.reverseBytes(Integer.reverseBytes(datum));
>         }
>         return v;
> was vectorized before but is considered "not profitable" with the changes here, causing slowdowns in such cases.

I'm not totally sure I fully get what you mean here: does this optimization hinder vectorization in some cases? Does this result in a slowdown? (BTW do you have benchmark results?) Should we possibly try to detect this early and avoid simplifying?

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

PR Review: https://git.openjdk.org/jdk/pull/23851#pullrequestreview-2653511319