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

[Jatin Bhateja]

On Mon, 20 Mar 2023 06:55:55 GMT, Xiaohong Gong <xgong 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
>
> src/hotspot/share/opto/inlinetypenode.cpp line 437:
> 
>> 435:         } else {
>> 436:           value = kit->access_load_at(base, adr, adr_type, val_type, bt, decorators);
>> 437:         }
> 
> Per my understanding, method "`record_method_not_compilable()`" is used here to record the compilation cannot continued by C2, right? So why do we still need to generate a `LoadVectorNode` as the field value before the recording? Will it have any issues if this node is used after then? I'm not familiar with this method. So please feel free to correct me.

In the initial patch I am preventing [C2 compilation](https://github.com/openjdk/valhalla/pull/833/files#diff-b0ea998b1ae6491c87dae54a2a70644f8e957e7f3522f780883d72fb29107aeaR433) and creating a dummy IR so that we can exit gracefully at a later point in compilation. We create Vector IR for loading/storing into multifield in a deeply nested routine. Ideally C2 should be compiling the fallback implementation but I do not think there is a way currently to ditch InlineType Node creation for value instances and treat them as regular identity instances. Other solution is to expose each ciFied separately to C2 compiler if target does not support specific vector size. As of now ci only expose base multi-field along with bundle size to ease Vector IR creation.

> src/hotspot/share/opto/inlinetypenode.cpp line 518:
> 
>> 516:         // all the concrete vectors should be fully flattened.
>> 517:         value = value->bottom_type()->isa_vect() ? value : kit->gvn().transform(VectorNode::scalar2vector(value, vec_len, val_type, false));
>> 518:         assert(value->bottom_type()->isa_vect() && value->bottom_type()->is_vect()->length() == (uint)ft->bundle_size(), "");
> 
> Is it possible that not all the multi-field values are the `value` here? For example, if the multi-fields in the InlineTypeNode have been changed before.

I do not fully follow your comment, multifield is not a value type to begin with, it the container VectorPayload* which is primitive class, for value types any change of field will result into creation of new InlineType, since values are immutable.

> src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java line 350:
> 
>> 348:         @MultiField(value = 8)
>> 349:         byte mfield = 0;
>> 350:         static long MFOFFSET = multiFieldOffset(VectorPayloadMF64B.class);
> 
> Any reason that we have to define the basic elment type to `mfield` for different type of VectorPayloadMF? We can do the `byte` type vector operations in compiler for multi-fields.

This is done to streamline vector IR type creation and prevent adding special handling in compiler to append a reinterpret IR post LoadVector. I wanted to prevent introducing any special handling in C2 which does not comply with Java code e.g. Float256Vector is backed by VectorPayload256MF @multifield(value = 64) byte mfield;.

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

PR: https://git.openjdk.org/valhalla/pull/833