RFR: 8357554: Enable vectorization of Bool -> CMove with different type size (on riscv)

[Hamlin Li]

On Tue, 3 Jun 2025 07:10:19 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> ( In this pr, it should return false for riscv too and be enabled in the riscv pr. I'll modify it. )
>> 
>>> Does RISCV support the use of any input vector element type, including 8bit, 16bit, 32bit and 64bit masks, and any elements we would be blending, incl byte, short, char, int, long, HF, F, D?
>> 
>> Good question! I'll add some additional tests to double check and reflect this.
>> 
>> I think the answer should be yes, i.e. on riscv all size of source inputs (comparing operands) and all size of dest outputs (blending result) are supported.
>> But for HF, it's a bit special, the underlying payload is a short, so in theory it should be supported too, but it's not supported in this pr and the related riscv pr (https://github.com/openjdk/jdk/pull/25341).
>> 
>>> Because it sounds you are promissing this really "unconditionally". Or what exactly do you mean by "unconditionally"?
>> 
>> I mean it's really "unconditionally", but if you feel it's better to add an argument, like `supports_vectorize_cmove_bool_unconditionally(BasicType src, BasicType dst)`, I can do it.
>> And I need to modify the `vectornode.cpp` as below too, I'll check it and modify this pr.
>> ```  case Op_CMoveI:
>>     return (is_integral_type(bt) && bt != T_LONG ? Op_VectorBlend : 0);
>
>> I mean it's really "unconditionally", but if you feel it's better to add an argument, like supports_vectorize_cmove_bool_unconditionally(BasicType src, BasicType dst), I can do it.
> 
> I think this would be good!

There is some issue when the comparison is unsigned one, e.g. `c[i] = Long.compareUnsigned(a[i], b[i]) > 0 ? 1.0 : 2.0;`, or `c[i] = (a[i] > b[i]) ? 1.0 : 2.0;` when a[]/b[] are char[].

Seems currently the unsigned comparison is not supported for superword vectorization? The unsigned information is lost, i.e. all the comparisons are just signed ones.
I checked the geneated code, and seems when VectorMaskCmp is matched, `BoolTest::unsigned_compare & cond` is always 0 in the passed in `cond` parameter.
(Vector API supports unsigned ones, as it passes in `cond` with `BoolTest::unsigned_compare` mask explicitly when the operator is in UGE/UGT/ULE/ULT.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25336#discussion_r2123518238