[vectorIntrinsics] RFR: RFC: Vector API masking support proposal for Arm SVE

[Ningsheng Jian]

On Mon, 15 Mar 2021 11:12:44 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi @jatin-bhateja 
>> 
>>> I have query regarding scalable vectors operand(vReg): Ideally type of machine node must comply with the type of its def machine operand, for scalable vector vReg::type() will always return a TypeVect::VECA (maximal vector size supported) irrespective of the type of MachTypeNode, this works fine because bottom_type() for MachTypeNode returns the type propagated to it from Ideal node during selection.
>>> 
>>> There are two places where this type in-consistency may show up:-
>>> 
>>> 1. If bottom type of machprojnode of a mask generating node is queried.
>>> 2. If someone directly queries the bottom type of def operand (ideally this should be rare)
>>> 
>>> We can fix 1) by returning the bottom type of incoming node of a MachProjNode. Do you foresee any penalty due to current inconsistencies, I am not able to think of one.
>>> 
>> 
>> I don't quite understand this inconsistency. Could you please elaborate a bit more? I am expecting a mask generating node would always get a TypeVMask (TypeVectMask) on supporting platform, which is pRegGovOper on SVE.
>> 
>>> Second observation (though not related to X86 or Masked operations), it seems you are spilling complete scalable vector (2048 bits) (MachSpillCopyNode::implementation)?
>> 
>> We are spilling the whole SVE register, which could be 128 bits to 2048 bits, depending on current running hardware implementation. So, the spilling size could be different depending on current SVE vector size of running process, while not the architecturally max (2048) bits. 
>> 
>>> I think resolving generic scalable vectors (2048 bits) to concrete ones (tightly coupled to machnode type) may prevent spilling extra bits.
>>> 
>> 
>> Thanks for looking at our backend implementation details and the suggestion. The generic vector register implementation sounds a good idea. However, for SVE, architecturally we have only one concrete vector type, SVE scalable vector register, though its size depends on different hardware implementations.
>> 
>> Thanks,
>> Ningsheng
>
>> I don't quite understand this inconsistency. Could you please elaborate a bit more? I am expecting a mask generating node would always get a TypeVMask (TypeVectMask) on supporting platform, which is pRegGovOper on SVE.
> 
> Hi @nsjian ,
> This question was related to SVE support,
> Function vRegOper::type() always returns Type::VECA.
> Type::VECA is initialized as maximal sized Scalable vector i.e. its size should be 2048 bit.  For a MachTypeNode having vReg as its def operand, will the def operand's type always match the bottom_type() of MachTypeNode?

Hi @jatin-bhateja ,

> Type::VECA is initialized as maximal sized Scalable vector i.e. its size should be 2048 bit. For a MachTypeNode having vReg as its def operand, will the def operand's type always match the bottom_type() of MachTypeNode?

Yes, I think so. On SVE target, we have only one vector type, TypeVect::VECTA and no other vector types. And it's real size is runtime detected, based on hardware implementation.

Thanks,
Ningsheng

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

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