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

[Jatin Bhateja]

On Fri, 12 Mar 2021 09:52:50 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>>> Hi Xiaohong (@XiaohongGong) ,
>>> Jatin is working on masking support. He will share his feedback, ideas and plans shortly with you.
>>> Best Regards,
>>> Sandhya
>> 
>> Hi @sviswa7 , thanks so much for telling this. It's really great if we can persistently share with each other.
>
> 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

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

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