RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I, MoveI2F

[Bhavana Kilambi]

On Thu, 24 Jul 2025 10:29:15 GMT, Galder Zamarreño <galder at openjdk.org> wrote:

> I've added support to vectorize `MoveD2L`, `MoveL2D`, `MoveF2I` and `MoveI2F` nodes. The implementation follows a similar pattern to what is done with conversion (`Conv*`) nodes. The tests in `TestCompatibleUseDefTypeSize` have been updated with the new expectations.
> 
> Also added a JMH benchmark which measures throughput (the higher the number the better) for methods that exercise these nodes. On darwin/aarch64 it shows:
> 
> 
> Benchmark                                (seed)  (size)   Mode  Cnt      Base      Patch   Units   Diff
> VectorBitConversion.doubleToLongBits          0    2048  thrpt    8  1168.782   1157.717  ops/ms    -1%
> VectorBitConversion.doubleToRawLongBits       0    2048  thrpt    8  3999.387   7353.936  ops/ms   +83%
> VectorBitConversion.floatToIntBits            0    2048  thrpt    8  1200.338   1188.206  ops/ms    -1%
> VectorBitConversion.floatToRawIntBits         0    2048  thrpt    8  4058.248  14792.474  ops/ms  +264%
> VectorBitConversion.intBitsToFloat            0    2048  thrpt    8  3050.313  14984.246  ops/ms  +391%
> VectorBitConversion.longBitsToDouble          0    2048  thrpt    8  3022.691   7379.360  ops/ms  +144%
> 
> 
> The improvements observed are a result of vectorization. The lack of vectorization in `doubleToLongBits` and `floatToIntBits` demonstrates that these changes do not affect their performance. These methods do not vectorize because of flow control.
> 
> I've run the tier1-3 tests on linux/aarch64 and didn't observe any regressions.

Although this is not in the scope of this patch, but I wonder if we could rename `ReinterpretS2HF` and `ReinterpretHF2S` to `MoveHF2S` and `MoveS2HF` to keep naming consistent with other types? WDYT @jatin-bhateja

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

PR Comment: https://git.openjdk.org/jdk/pull/26457#issuecomment-3144464995