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

[Dean Long]

On Thu, 6 Feb 2025 23:29:51 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.

It's not clear what result you are expecting from the new shift code when it overflows.  It looks like signed overflow undefined behavior (UB) to me, which would ideally be caught by UBSAN, so you probably want to make sure your changes are ubsan-clean.  If the desired result for overflow is 0, then I think java_shift_left() should be used.

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

Changes requested by dlong (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23506#pullrequestreview-2600434103