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

[Ningsheng Jian]

On Mon, 15 Mar 2021 09:42:04 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi, I have to force push all the codes again to resolve the conflicts due to the latest merging from jdk master. Thanks!
>
> Hi @XiaohongGong , @nsjian 
> 
> 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. 
> 
> Second observation (though not related to X86 or Masked operations),  it seems you are spilling complete scalable vector (2048 bits) (MachSpillCopyNode::implementation)? 
> I think resolving generic scalable vectors (2048 bits) to concrete ones (tightly coupled to machnode type) may prevent spilling extra bits. 
> 
> Best Regards,
> Jatin

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

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

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