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

[Xiaohong Gong]

On Wed, 19 May 2021 06:42:41 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.
>
> @jatin-bhateja , did you see any issue if the type of `VectorBox/VectorUnbox ` is not the enveloped vector type?

I found out another reason why I need to set the `TypeVectMask` for `VectorBox/Unbox`. This is mainly used to make the assertions for mask inputs work well when creating a masked node, like the assertion in:

StoreVectorMaskedNode(Node* c, Node* mem, Node* dst, Node* src, const TypePtr* at, Node* mask)
   : StoreVectorNode(c, mem, dst, at, src) {
    assert(mask->bottom_type()->isa_vectmask(), "sanity");
    init_class_id(Class_StoreVector);
    set_mismatched_access();
    add_req(mask);
  }

If the `StoreVectorMaskedNode` is created before expanding the `VectorUnbox` nodes, the mask value might be a `VectorUnbox`  which has a `TypeVect` type while not the expected mask type. And then the assertion will fail. We can also remove all the assertions in the constructor methods to make a workaround. But I think it's not a safe way. Any better idea to handle the conflicts? Thanks!

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

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