RFR: 8286847: Rotate vectors don't support byte or short [v3]

[Jatin Bhateja]

On Wed, 18 May 2022 07:01:00 GMT, Haomin <duke at openjdk.java.net> wrote:

>> static void test_fun(byte[] a0, int[] b0, byte[] c0) {
>>     for (int i=0; i<ARRLEN; i++) {
>>       c0[i] = (byte)(a0[i] << (7) | a0[i] >>> (-7));
>>     }   
>>   }
>> 
>> 
>> when I implement RotateLeftV in loongarch.ad, I found this executed by c2 vector and executed by interpreter are not equal.
>> 
>> It's executed on x86 would create an assert error.
>> 
>> 
>>  # Internal Error (/home/wanghaomin/jdk/src/hotspot/share/opto/vectornode.cpp:347), pid=26469, tid=26485
>>  # assert(false) failed: not supported: byte
>> 
>> 
>> RotateLeftV for byte, short values produces incorrect Java result. Because java code should convert a byte, short value into int value, and then do RotateI.
>
> Haomin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   merge the two cases into one

You are seeing this problem in auto-vectorizer flow which if folding (byte)(a0[i] << (7) | a0[i] >>> (-7)); into scalar rotate IR.
I think we can remove unsupported type assertion from  VectorNode::is_vector_rotate_supported since there is no direct x86 vector rotate instruction. There are ways to handle it by unpacking sub-word lanes to integer lanes followed by vector rotation but its currently not supported and also we saw better performance on dismantling rotate into shifts and or operations.

src/hotspot/share/opto/vectornode.cpp line 157:

> 155:     case T_LONG: return Op_RotateLeftV;
> 156:     default:     return 0; // RotateLeftV for byte, short values produces incorrect Java result.
> 157:                            // Because java code should convert a byte, short value into int value,

Current handling creates a vector rotate IR nodes for all integral types and later on dismantles it into constituent operation (SHIFTs and ORs).  Idea behind this to intrinsify lanewise vector operation for any integral type.

Your above change will prevent intrinsification and test may still pass.

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

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