RFR: 8359419: AArch64: Relax min vector length to 32-bit for short vectors [v3]

[Fei Gao]

On Mon, 7 Jul 2025 06:59:20 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/test/hotspot/jtreg/compiler/vectorization/runner/ArrayTypeConvertTest.java#L388-L392
> 
> Actually I didn't change the min vector size for `char` vectors in this patch. Relaxing `short` vectors to 32-bit is to support the vector cast for Vector API, and there is no `char` species in it. Do you think it's better to do the same change for `char` as well? This will just benefit auto-vectorization.

Hi @XiaohongGong thanks for asking. In many auto-vectorization cases involving `char`, the vector elements are represented using `T_SHORT` as the `BasicType`, rather than `T_CHAR`.

This is because, in Java, operands of subword types are always promoted to `int` before any arithmetic operation. As a result, when handling a node like `ConvD2I`, we don’t initially know its actual subword type. Later, the SuperWord phase propagates a narrowed integer type backward to help determine the correct subword type. See:
https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/share/opto/superword.cpp#L2551-L2558

Since SuperWord assigns `T_SHORT` to `StoreC` early on https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/share/opto/superword.cpp#L2646-L2650
the entire propagation chain tends to use `T_SHORT` as well. 

This applies to most operations, with the exception of a few like `RShiftI`, `Abs`, and `ReverseBytesI`, which are handled separately.

So your change already benefits many char-related vectorization cases like `convertDoubleToChar` above. That’s why we can safely relax the IR condition mentioned earlier.

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

PR Comment: https://git.openjdk.org/jdk/pull/26057#issuecomment-3045113900