RFR: 8346236: Auto vectorization support for various Float16 operations [v8]

Jatin Bhateja jbhateja at openjdk.org
Fri Mar 28 18:39:40 UTC 2025


On Fri, 28 Mar 2025 11:21:42 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Some re-factoring
>
> test/hotspot/jtreg/compiler/lib/generators/Generators.java line 172:
> 
>> 170:      * Generates uniform float16s in the range of [lo, hi) (inclusive of lo, exclusive of hi).
>> 171:      */
>> 172:     public RestrictableGenerator<Short> uniformFloat16s(short lo, short hi) {
> 
> Hmm, passing `short` into this API seems a little strange to me. Because the range `[lo, hi)` doesn't really make sense... rather it is the bits by `lo` and `hi` interpreted as `Float16`... but isn't that a little cumbersome? Why not pass in `Float16` instead?

We want to avoid making a reference to an incubating class for now as every test using generator will then need to --add-modules=jdk.incubator.vector. Also, this will not pose any issue when we add a new Generator<Short> for short values since underlines framework APIs will be different from the once used for float16 generator with Short carrier type.

> test/hotspot/jtreg/compiler/lib/generators/Generators.java line 375:
> 
>> 373:      * @return Random float16 generator.
>> 374:      */
>> 375:     public Generator<Short> float16s() {
> 
> Why do you not generate a `Float16` here? This here would probably conflict with a future `Short` generator which we might add in the future....

To avoid dependency on an incubating module.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22755#discussion_r2019151114
PR Review Comment: https://git.openjdk.org/jdk/pull/22755#discussion_r2019154395


More information about the hotspot-compiler-dev mailing list