[lworld+vector] RFR: 8304310: Initial compilers and runtime handling for multifield backed vectors.
Xiaohong Gong
xgong at openjdk.org
Tue Mar 21 02:11:12 UTC 2023
On Mon, 20 Mar 2023 09:49:41 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:
>> 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;.
OK, make sense to me. Per my understanding, it currently only has `load/store/zero` vector operations for the multi-fields, right? Hence always using byte vector operations may also work well to me. But making the vector type accurate with the concrete vector class type is better for compiler. So this change is fine to me. Thanks!
-------------
PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1142830096
More information about the valhalla-dev
mailing list