On Tue, 8 Jul 2025 08:18:57 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?

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

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

Reply via email to