[vector api] RFR: Implement Vector API andAll/orAll/xorAll for AArch64 NEON

[Ningsheng Jian (Arm Technology China)]

Hi John,

On 4/27/19 8:26 AM, John Rose wrote:
> Sandhya and the other Intel engineers are currently working on
> the problem of AD file size.  They report they can reduce the
> number of instructions by having one instruction support
> many match rules, in the common case where one instruction
> format performs a range of similar operations.  This does
> not immediately reduce the size of the AD file, because
> the adlc preprocessor internally duplicates such instructions,
> once per match rule.  But some additional adlc work should
> be able to refactor the generated code to be less repetition,
> and therefore smaller.  I hope this work comes to the light
> of day soon, so ARM can make use of it also.
> 

Thanks for the sharing. I think you mean this patch from Sandhya [1]. 
Yang has reviewed the first version - she is on her sabbatical now. We 
are aware of the size concern from Vladimir, and I did find some 
possible improvements for AArch64 AD file. I will see how the new webrev 
goes.

> On another note, you've probably noticed the rapid set
> of pushes to the vector branch of panama.  We are still
> hammering on the API design, of course, but it seems to
> be cooling down a bit.  Now would be a great time for
> vector experts on ARM to look at the javadoc and see if
> there's anything in there that (accidentally) has semantics
> that is too x86-specific, or is otherwise non-portable.
> 
> Here's a recent javadoc from Kishor Kharbas:
> 
> http://cr.openjdk.java.net/~kkharbas/vector-api/javadoc/VectorApi-JavaDoc.05/jdk.incubator.vector/jdk/incubator/vector/package-summary.html
> 
> http://cr.openjdk.java.net/~kkharbas/vector-api/javadoc/
> 
> It's good reading!  After we all work it over it will be even better,
> of course.  There will also be a formal CSR review in the not-too-distant
> future, since that is part of the JEP process.

We (Arm) are following the changes of the API. With a formal CSR review, 
a wider community will also be involved. I think the cleanup work by 
Kishor generally looks good and we may have some comments after a more 
detailed review of current API.

[1] 
http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-April/033339.html

Thanks,
Ningsheng