[aarch64-port-dev ] RFR(S): 8214922: Add vectorization support for fmin/fmax

Pengfei Li (Arm Technology China) Pengfei.Li at arm.com
Tue Dec 25 11:19:05 UTC 2018


> > Yes. Worse than that, it's a piece of
> > AArch64-microarchitecture-specific
> > logic in shared code. So it doesn't even apply to all AArch64
> implementations.
> bool ReductionNode::implemented(int opc, uint vlen, BasicType bt) {
>   if (is_java_primitive(bt) &&
>       (vlen > 1) && is_power_of_2(vlen) &&
>       Matcher::vector_size_supported(bt, vlen)) {
>     int vopc = ReductionNode::opcode(opc, bt);
>     return vopc != opc && Matcher::match_rule_supported(vopc);
>   }
>   return false;
> }
> Could this be done in Matcher::vector_size_supported() with some changes
> to the signature of that method?

Thanks for all your valuable feedbacks. As Andrew said this kind of logic is microarchitecture-specific, checking vector length in any code would be not necessary, I suppose.

Please see below new webrev in which the condition of "Matcher::max_vector_size(T_FLOAT) > 2" is totally removed and more matching rules are added in ad file.
I tested this with my original JMH case[1] on more different AArch64 CPUs. On most of them, the performance of min/max reduction for doubles gets neither better nor worse.

BTW: I'm also struggling to find a simple JMH case which can trigger reduction auto-vectorization.

[1] http://cr.openjdk.java.net/~pli/rfr/8214922/TestSIMDFpMinMax.java


More information about the hotspot-compiler-dev mailing list