[lworld+vector] RFR: 8304310: Initial compilers and runtime handling for multifield backed vectors. [v5]

[Xiaohong Gong]

On Thu, 6 Apr 2023 08:58:21 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Please find below the summary of changes included with the patch:
>>   
>> a) _ci Model:_
>>    oops model creates separate fieldDescriptor/FieldInfo for each scalar field of a multifield bundle, root field is marked as multifield_base and non -  root (synthetic) fileds carry a multifield flag. To ease vector IR construction ci only exposes base multifield and ciType holding bundle size to compilers.
>> 
>> b) _C1 compiler:_
>>    Special handling to copy entire multifield bundle during withfield bytecode processing.
>> 
>> c) _C2 compiler:_
>>    VectorBox becomes a derivative of InlineType IR node, changes in vector box/unbox expansions. Preventing scalarization of Vector arguments and return values.
>> 
>> d) _Runtime:_
>>    Changes in object re-construction during deoptimization since now concrete vectors have multifield based payloads. Payload (VectorPayloadMF) is a primitive class object which gets fully flattened within its parent/holding instance i.e. a concrete vector, special handling has been added for non-flattened case where payload is allocated over heap and concrete vector payload field is assigned its reference.
>> 
>> e) Added type specific multifield payloads to ease vector IR creation by C2, this will ensure bundle type and C2 IR type are compatible.               
>> 
>> Scope of current changes is limited to Vector types only, shuffles and masks are still backed by array based payloads. This PoC patch has been validated over vector only tests. More robust validation will be done in due course.
>> 
>> More information can be found at following link
>> [https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx](https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx)
>> 
>> Please share your feedback and suggestions.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup vector box expansion handling to leverage existing InlineTypeNode storage and flow merging routines.

src/hotspot/share/opto/vectornode.hpp line 1689:

> 1687:     payload_value->as_InlineType()->set_field_value(0, val);
> 1688:     payload_value = gvn.transform(payload_value);
> 1689:     VectorBoxNode* box_node = new VectorBoxNode(vk, box, false, vk->is_empty() && vk->is_initialized());

I think we have to keep the `val` as the input of the new `VectorBoxNode`, and moving the payload creating code to the `expand_vbox_node` as before.  `VectorBoxNode` is a macro node for a vector. So it's more reasonable it only contains the vbox and vec parts. The payload creating should belong to the extension stage like before. Besides, some transformation applied to `PhiNode` may expect one of the input of  `VectorBoxNode` is a vector type?

I met a jvm crash issue with following test case on ARM NEON system:

 var av = IntVector.fromArray(I_SPECIES, ia, 0);
 for (int i = 0; i < LENGTH; i += vl) {
       var bv = IntVector.fromArray(I_SPECIES, ib, i);
       av = av.and(bv);
 }
 av.intoArray(ic, 0);

The log shows it crashes when the type is not mismatch at a `PhiNode`.  One is `TypeVectX`, and another is `TypePtr`. I didn't dig into the `cfgnode.cpp` to see what is wrong. But as a try, I moved this code to the expanding stage, the issue is gone.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1161522886