VectorAPI Scatter Gather Intrinsic Support

[Vladimir Ivanov]

On 03/12/2018 21:06, Rukmannagari, Shravya wrote:
> Hi Vladimir,
> Please find the comments below and a modified patch with the changes suggested:
> http://cr.openjdk.java.net/~srukmannagar/VectorAPI_ScatterGather/webrev.01/
> 
>> While looking through the implementation, I couldn't find a compelling reason for the current API representation (indices as an >array):
>>
>>     void intoArray($type$[] a, int ix, int[] b, int iy)
>>
>> and not as a vector:
>>
>>    void intoArray($type$[] a, int ix, Vector<Integer,S> vecInd)
>>
>> The latter form looks much more flexible and generic.
>>
>> Can anybody remind me what was the motivation for such particular shape?
>> Sub-word types (byte, short)? Is it still relevant considering the patch removes relevant declarations from ByteVector/ShortVector?
> This is a factory method and all the currently implemented intrinsics take array as the input, which is more generic to the user than a vector. Also, this was a use case provided by Adam Pocock and we therefore decided to go with the current implementation.

IMO it's more generic only in the case of sub-word types where 
corresponding index vector is larger than value vector and has to be split.

Otherwise, vector index looks more generic to me. It's trivial to load a 
vector from index array, but if you have a vector and need to pass it as 
an array, it's hard to get the vector store into interim array optimized 
away.

So, if sub-word types are out of scope for scatters/gatherers, I'm in 
favor of vector indices.

FTR it's more about followup API refinements, so no need to change 
anything on API level as part of this particular change.

>> Regarding implementation:
>>
>> ========================================================================
>>
>> src/hotspot/cpu/x86/x86.ad:
>>
>> +#ifdef _LP64
>>
>> Why don't you put the changes in x86_64.ad then?
> x86_64.ad file does not have few registers and variables defined. For instance vecZ is undefined.

Those declarations should be moved to x86_64.ad as well. For example, 
other vector operands (e.g., vecY/legVecY/...) are declared in 
x86_[32|64].ad and automatically imported into x86.ad from there.

Best regards,
Vladimir Ivanov