[lworld+vector] RFR: 8314628: [lworld+vector] validation regression fixes and cleanups.

[Xiaohong Gong]

On Tue, 22 Aug 2023 10:15:33 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/share/classfile/javaClasses.cpp line 4989:
>> 
>>> 4987:   o->obj_field_put(_payload_offset, val);
>>> 4988: }
>>> 4989: 
>> 
>> Can we also clean-up the classfile symbols in https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/classfile/vmClassMacros.hpp#L197 and https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/classfile/vmSymbols.hpp#L97 ?
>
> I am planning to use these symbol definitions in Max species support, estimation of multifield bundle size for max species cannot be just done based on MaxVectorSize, e.g., both LongMaxMask and ByteMaxMask will encapsulate VectorPayloadMFMaxZ which will hold @multifield(-1) annotated boolean mfield.
> 
> In order to determine the bundle size, we need to resort to VM symbol name comparison during field parsing, payload class names should also be different for Byte and Long max species mask e.g. VectorPayloadMFMaxZL and VectorPayLoadMFMaxZB. Bundle size for Long should be 8 while for Byte should be 64 for 512-bit MaxVectorSize.

I also spent some time looking at this part. It's true that we have to distingunish the max lanecount for different types of VectorMask. As for this part, maybe we could also extend the `MultiField` annotation by adding another variable denotaing the type info like `esize/scale`. And calculate the right lanecount based on the `MaxVectorSize` and `esize/scale` when parsing classfile. WDYT?

>> src/hotspot/share/opto/library_call.cpp line 2658:
>> 
>>> 2656:   }
>>> 2657:   InlineTypeNode* vt = buffer->as_InlineType();
>>> 2658:   if (!vt->is_allocated(&_gvn) || VectorSupport::is_vector_payload_mf(vt->inline_klass()->get_InlineKlass())) {
>> 
>> This will make the `finishPrivateBuffer` un-inlined in all Vector API cases, won't it? This seems not so efficient to me. But I cannot find a better way to fix the masked cases now.
>
> You are right, but it will not affect the performance given that code is part of fallback implementation.

OK, it's fine to me now. We can revisit this part and fine tune if possible in future. Thanks!

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/909#discussion_r1302355132
PR Review Comment: https://git.openjdk.org/valhalla/pull/909#discussion_r1302356259