RFR: 8356813: Improve Mod(I|L)Node::Value [v6]

[Hannes Greule]

On Mon, 25 Aug 2025 13:18:28 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> Looks really good now. I think we can almost integrate now.

Thanks for the review :)

> One thing I'm wondering: could this be extended to `UModI/L`? That can of course be a separate RFE as well. And yet another idea: could we use the known bits? See #17508.

Yes, `UModI/L` could be done now in a similar fashion using usigned ranges. I can open an RFE later. I'm not sure if we can get more precise bitwise information than what the canonicalization already does. I don't see anything obvious there at least.

> Can you show some examples? Filing an RFE would surely not be wrong.

https://gist.github.com/SirYwell/151a48c90d12593bf500028389bdd07c this is an example. (Currently, we don't detect patterns like `Math.floorMod(...)`, so I'm just casting to char to get a nonnegative value).
In the patched version, I added a bailout in `transform_int_divide` to to delay the transformation to IGVN. This way, we actually run `ModI::Value()` and get a type that lets us eliminate the CmpU. There are probably better ways to achieve that :) I wonder if there are more such scenarios, and if it's worth to calculate some initial type before `Ideal()`...

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

PR Comment: https://git.openjdk.org/jdk/pull/25254#issuecomment-3224071958