[vectorIntrinsics+mask] RFR: 8266287: Basic mask IR implementation for the Vector API masking feature support [v2]

[Jatin Bhateja]

On Wed, 16 Jun 2021 09:34:46 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> src/hotspot/share/opto/vectorIntrinsics.cpp line 84:
>> 
>>> 82:   assert(check_vbox(vbox_type), "");
>>> 83:   const TypeVect* vt = is_vector_mask(vbox_type->klass()) ?
>>> 84:                        TypeVect::makemask(elem_bt, num_elem) : TypeVect::make(elem_bt, num_elem);
>> 
>> Box type which is an envelope type should still be the same e.g. Int256VectorMask. Value contained in the Masked Box should be of type vectmask.
>
> Hi @jatin-bhateja , it seems the type of `VectorBox/VectorUnbox` should be exactly matched with the `value` boxed. For such an optimization `// VectorUnbox (VectorBox v) ==> v`, if the type of `v` is a vector mask type while the `VectorUnbox` type is expected to be a vector type, the final result of this optimization would change the result type of `VectorUnbox` to be a mask type. Some type checks or assertion will fail. I met the following issue when I run the jtreg tests after changing type of `VectorBox/VectorUnbox` back to vector type:
> 
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (/home/ent-user/panama-vector/src/hotspot/share/opto/type.cpp:2412), pid=433543, tid=433698
> #  Error: assert(base() == v->base()) failed
> #
> # JRE version: OpenJDK Runtime Environment (17.0) (fastdebug build 17-internal+0-git-8123588d66)
> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 17-internal+0-git-8123588d66, mixed mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
> # Problematic frame:
> # V  [libjvm.so+0x19f3108]  TypeVect::xmeet(Type const*) const+0x138
> #
> # Core dump will be written. Default location: Core dumps may be processed with "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %e" (or dumping to /home/ent-user/jtreg/jtreg-hg/build/images/jtreg/jtwork/scratch/2/core.433543)
> #
> # If you would like to submit a bug report, please visit:
> #   https://bugreport.java.com/bugreport/crash.jsp
> 
> Do you have any strong reason that we must define a vector type for `VectorBox/VectorUnbox`?

VectorBoxNode and VectorUnboxNode are macro nodes and carry the vector type which comply with the species i.e. for IntVector.SPECIES_256, vector type of Box/Unbox should be TypeVect(T_INT,8), both these nodes needs to be expanded as per following expansion rules:- 

a) VectorBox mask(TypeVectMask) ====>   VectorStoreMask + StoreVector.
b) VectorUnbox mask =====>  LoadVector  + VectorLoadMask (TypeVectMask)
c) VectorUnbox (VectorBox mask) ====> VectorStoreMask(TypeVectMask) + StoreVector + LoadVector + VectorLoadMask(TypeVectMask)

An optimization over VectorUnboxNode should consult the type of VectorBoxNode and vice-versa,  similarly any optimization involving VectorLoadMaskNode should comply with type of VectoStoreMaskNode, there cannot be a mix-match, if there is any such case it needs to be fixed like the following handling
https://github.com/openjdk/panama-vector/pull/90#pullrequestreview-679559503

Can you kindly share the tests which failed.

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

PR: https://git.openjdk.java.net/panama-vector/pull/78