On Tue, 8 Jul 2025 10:33:50 GMT, Fei Gao <f...@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. > > > > > > > > > > > > Thanks for your input! It's really helpful to me. Does this mean it > > > > always use `T_SHORT` for char vectors in SLP? If so, it's safe that we > > > > do not need to consider `T_CHAR` in vector IRs in backend? > > > > > > > > > No, we don't always use `T_SHORT` for char vectors. As mentioned earlier, > > > for operations like `RShiftI`, `Abs`, and `ReverseBytesI`, the compiler > > > needs to preserve the higher-order bits of the first operand. Therefore, > > > SuperWord still needs to assign them precise subword types. See: > > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/share/opto/superword.cpp#L2583-L2589 > > > > > > Yes, I see. Thanks! What I mean is for cases that SLP will use the subword > > types, it will be actually `T_SHORT` for `T_CHAR` then? > > From my side, the cases where SLP uses subword types can be roughly > categorized into two groups: > > 1. Cases where the compiler doesn’t need to preserve the higher-order bits — > in these, SuperWord will use `T_SHORT` instead of `T_CHAR`. > 2. Cases where the compiler does need to preserve the higher-order bits, like > `RShiftI`, `Abs`, and `ReverseBytesI` — in these, `T_CHAR` is still used.
Thanks for your explanation! I'v updated the ad file and jtreg tests in latest commit. Could you please take a look at again? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26057#issuecomment-3050732618
