RFR: 8335444: Generalize implementation of AndNode mul_ring [v3]

Christian Hagedorn chagedorn at openjdk.org
Mon Aug 19 12:11:54 UTC 2024


On Wed, 31 Jul 2024 17:12:47 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> I actually did experiment with this before coming up with the current approach, but I found that there are cases where it produces incorrect bounds. With a small example where `r0 = [-3, -1]` and `r1 = [-7, -1]`, using `r0->_lo & r1->_lo` results in `-3 & -7`, which equals `-7`. However, in the case where the value in `r0` is `-3` and `r1` is `-6`, we can get an out of bounds result as `-3 & -6` equals `-8`. Because of that I thought the best way to fix this was to find the common leading 1s. This approach does lead to us losing some information in the lower-order bits but I thought it was an acceptable compromise since the code to handle finding common bits across a range of integers becomes quite a bit more complicated. I hope this clarifies!
>
> You're totally right! It is not even related to the LSB (`-14 & -6` would have the same problem with `-12`). Finding the leading 1s is the right solution. Thanks a lot for the clarification!

Can the upper limit be improved similar to what you added for the "both ranges are positive" case if we know that both ranges are negative?
In the positive case, we have values from:

011...1
000...0
``` 
while in the negative case, we have values from:

111...1
100...0

It suggests that we can then use the same argument as for the positive case and say that the maximum will be the maximum of the smaller range (i.e. `MIN2(r0->_hi, r1->_hi)`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20066#discussion_r1721669165


More information about the hotspot-compiler-dev mailing list