RFR: 8347555: [REDO] C2: implement optimization for series of Add of unique value [v21]

[Roland Westrelin]

On Mon, 6 Oct 2025 14:17:10 GMT, Kangcheng Xu <kxu at openjdk.org> wrote:

>> [JDK-8347555](https://bugs.openjdk.org/browse/JDK-8347555) is a redo of [JDK-8325495](https://bugs.openjdk.org/browse/JDK-8325495) was [first merged](https://git.openjdk.org/jdk/pull/20754) then backed out due to a regression. This patch redos the feature and fixes the bit shift overflow problem. For more information please refer to the previous PR.
>> 
>> When constanlizing multiplications (possibly in forms on `lshifts`), the multiplier is upgraded to long and then later narrowed to int if needed. However, when a `lshift` operand is exactly `32`, overflowing an int, using long has an unexpected result. (i.e., `(1 << 32) = 1` and `(int) (1L << 32) = 0`)
>> 
>> The following was implemented to address this issue.
>> 
>> if (UseNewCode2) {
>>     *multiplier = bt == T_INT
>>         ? (jlong) (1 << con->get_int()) // loss of precision is expected for int as it overflows
>>         : ((jlong) 1) << con->get_int();
>> } else {
>>     *multiplier = ((jlong) 1 << con->get_int());
>> }
>> 
>> 
>> Two new bitshift overflow tests were added.
>
> Kangcheng Xu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use constructor, improve readability

src/hotspot/share/opto/addnode.cpp line 451:

> 449:     con = phase->intcon(java_add(static_cast<jint>(mul.multiplier()), 1));
> 450:   } else {
> 451:     con = phase->longcon(java_add(mul.multiplier(), static_cast<jlong>(1)));

Instead of casting to `jlong`, you can use `CONST64(1)`.

src/hotspot/share/opto/addnode.cpp line 561:

> 559:     // Pattern (2)
> 560:     if (lhs.is_valid_with(n->in(2))) {
> 561:       return Multiplication(lhs.variable(), java_add(lhs.multiplier(), static_cast<jlong>(1)));

Same here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23506#discussion_r2406630926
PR Review Comment: https://git.openjdk.org/jdk/pull/23506#discussion_r2406642003