On Tue, 3 Nov 2026 14:28:31 GMT, jonghoonpark <[email protected]> wrote:
>> test/hotspot/jtreg/serviceability/sa/LingeredAppWithVector.java line 32:
>>
>>> 30: public class LingeredAppWithVector extends LingeredApp {
>>> 31:
>>> 32: private static final VectorSpecies<Integer> SPECIES =
>>> IntVector.SPECIES_128;
>>
>> I think it would be good to also test this will all other vector types, no?
>> What happens with floats, for example?
>
> @eme64 Thanks for the review! I've updated the test based on your feedback.
>
> - Added 10 vector types: all six element types for 128-bit, and
> Byte/Short/Int/Float for 64-bit.
> - Excluded `LongVector64` and `DoubleVector64`, which have a single lane:
> - `LongVector64`: C2 rejects both load and reduction on aarch64 and x86.
> - `DoubleVector64`: rejected on aarch64. On x86, the load is allowed, but
> the reduction is still rejected.
>
> (x86 was checked under Rosetta)
>
> As for floats, both `FloatVector128` and `FloatVector64` decode as
> `Location::vector`.
Any chance you could just iterate over ALL vector types (element types and
sizes), including `Float16Vector` as well?
I know that not all of those actually will generate vectors on all platforms.
But it would still be good to exercise all variants, in case more of them are
supported by hardware in the future. The SA should generate something sensible
for all cases, right? So either a SIMD vector or the object wrapping the array
payload.
You can of course also have a list of vector types where you expect to get the
SIMD vector, and and assert that - as you are doing now.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/33665#discussion_r4457299589
