RFR: 8335444: Generalize implementation of AndNode mul_ring

[Damon Fenacci]

On Mon, 8 Jul 2024 03:37:30 GMT, Jasmine Karthikeyan <jkarthikeyan at openjdk.org> wrote:

> Hi all,
> I've written this patch which improves type calculation for bitwise-and functions. Previously, the only cases that were considered were if one of the inputs to the node were a positive constant. I've generalized this behavior, as well as added a case to better estimate the result for arbitrary ranges. Since these are very common patterns to see, this can help propagate more precise types throughout the ideal graph for a large number of methods, making other optimizations and analyses stronger. I was interested in where this patch improves types, so I ran CTW for `java_base` and `java_base_2` and printed out the differences in this gist [here](https://gist.github.com/jaskarth/b45260d81ab621656f4a55cc51cf5292). While I don't think it's particularly complicated I've also added some discussion of the mathematics below, mostly because I thought it was interesting to work through :)
> 
> This patch passes tier1-3 testing on my linux x64 machine. Thoughts and reviews would be very appreciated!

Changes requested by dfenacci (Committer).

src/hotspot/share/opto/mulnode.cpp line 638:

> 636: 
> 637:   // Since the result of bitwise-and can be as high as the largest value of each range, the result should find the maximum.
> 638:   return IntegerType::make(std::numeric_limits<NativeType>::min() >> shift_bits, MAX2(r0->_hi, r1->_hi), widen);

I was just wondering if it would be OK to use `(r0->_lo & r1->_lo)` as the minimum value instead of finding the number of leading 1s and shifting. It seems to be a bit more constrained and compact (and seemingly correct). What do you think?

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

PR Review: https://git.openjdk.org/jdk/pull/20066#pullrequestreview-2209972764
PR Review Comment: https://git.openjdk.org/jdk/pull/20066#discussion_r1698395406