On Thu, 24 Jul 2025 10:29:15 GMT, Galder Zamarreño <gal...@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
