RFR: 8283307: Vectorize unsigned shift right on signed subword types

Quan Anh Mai duke at openjdk.java.net
Thu Apr 21 02:31:25 UTC 2022


On Wed, 20 Apr 2022 04:07:24 GMT, Fei Gao <fgao at openjdk.org> wrote:

>> @fg1417 Thanks a lot for your kind explanation, it makes sense now. Do you think it is worth it to generalise to the remaining cases, that is
>> 
>>     0 < c < esize:
>>     (type)((int)a >>> c) -> a >> c
>> 
>>     esize <= c <= 32 - esize:
>>     (type)((int)a >>> c) -> a >> (esize - 1)
>> 
>>     32 - esize < c < 32:
>>     (type)((int)a >>> c) -> (a >> (esize - 1)) >>> (c - (32 - esize))
>> 
>> Here `>>` and `>>>` are true unsigned shifts on the operand types, not exactly the Java scalar operations which actually work on promoted types.
>
>> ```
>> 0 < c < esize:
>> (type)((int)a >>> c) -> a >> c
>> 
>> esize <= c <= 32 - esize:
>> (type)((int)a >>> c) -> a >> (esize - 1)
>> 
>> 32 - esize < c < 32:
>> (type)((int)a >>> c) -> (a >> (esize - 1)) >>> (c - (32 - esize))
>> ```
>> 
>> Here `>>` and `>>>` are true unsigned shifts on the operand types, not exactly the Java scalar operations which actually work on promoted types.
> 
> Thanks for your kind reply, @merykitty . 
> 
> I suppose the first two scenarios have been covered in the pr. `esize` for byte is 8 and `esize` for short is 16, and the pr covers the range from 0-24 for byte and the range from 0-16 for short. But may I ask why the shift amount is `esize-1` rather than `esize` itself in the second scenario when `esize <= c <= 32 - esize`? 
> 
> For the third scenario, the idea works and generalizing to cover more cases is absolutely good. However, the true unsigned shifts `>>>` on the right of induction may make people confused, if there are two different unsigned right shift vector operations on the same data type in one patch. It's not easy to review. I mean maybe we can do it with another patch. WDYT? 
> 
> Thanks a lot.

@fg1417

> But may I ask why the shift amount is `esize-1` rather than `esize` itself in the second scenario when `esize <= c <= 32 - esize`?

Because `a >> esize == a`, similar to how scalar integer and long shifts work, vector shifts on bytes and shorts mask the shift counts to the least significant 3, 4 bits, respectively.

> However, the true unsigned shifts `>>>` on the right of induction may make people confused, if there are two different unsigned right shift vector operations on the same data type in one patch.

It is not that confusing I think, vector shifts always consider bytes and shorts as first-class types, not dress-up ints as in scalar circumstances, but it is upon your decision.

Thanks.

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

PR: https://git.openjdk.java.net/jdk/pull/7979


More information about the hotspot-compiler-dev mailing list