RFR: 8282365: Optimize divideUnsigned and remainderUnsigned for constants [v4]

[Quan Anh Mai]

On Thu, 29 Sep 2022 18:30:48 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> May you expand on this, please? How can I know that a divisor is negative without using its type information? Thanks.
>
> What I am trying to say is that you can not replace removed runtime code in `C2_MacroAssembler` with only this code in IR (which covers only part of cases). You need additional code for case when divisor is not constant and its type is unknown. You need to generate IR code similar to runtime code with explicit runtime check for negative divisor and calculation `(dividend & ~(dividend - divisor)) >>> (Integer.SIZE - 1)`. Which will be very disruptive for IR graph.
> 
> My suggestion is to leave this your code for cases when type is known - it will allow to avoid `div` instruction generation and it is good. But also restore `C2_MacroAssembler` code you removed - it will cover the rest of cases when type (negativity) of divisor is not known during compilation.

Thanks for your explanation. I believe this can be achieved by changing the name of the intrinsic to `divideUnsigned0` and implementing `Integer/Long::divideUnsigned` as follow:

    int divideUnsigned(int dividend, int divisor) {
        if (divisor > 0) {
            return divideUnsigned0(dividend, divisor);
        } else if (divisor < 0) {
            return compareUnsigned(dividend, divisor) >= 0 ? 1 : 0;
        } else {
            throw new ArithmeticException();
        }
    }

However, I think that this is premature optimisation as:

- Integer values are heavily biased toward 0, in unsigned contexts, a negative divisor is a really large divisor, which is highly unlikely. As a result, this results in redundant code for the majority of cases.
- This optimisation can be implemented purely in Java, which means that the users of this method can implement it themselves if it is known that the distribution of divisors is different from the general cases.

If you don't agree then I would implement the optimisation in Java as presented above. Thanks very much.

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

PR: https://git.openjdk.org/jdk/pull/9947