[PATCH] 8217561 : X86: Add floating-point Math.min/max intrinsics, approval request

[B. Blaser]

On Mon, 18 Feb 2019 at 17:25, Andrew Haley <aph at redhat.com> wrote:
>
> This message is hard to interpret. The question is whether we should
> be sure that adding an intrinsic will help Java performance. I don't
> know what your point is. Of course there will be some cases where an
> intrinsic actually helps, even in the case of a reduction. Whoever
> said otherwise? The question is whether, on average or in typical,
> such an intrinsic will make Java better. We have not answered that
> question, but we are still talking about pushing this intrinsic.
>
> Intel themselves are quite clear in their optimization guide that the
> MIN/MAX instructions should be used only when the branch isn't
> predictable. We have profile data when generating code in C2, so we
> know enough to make an intelligent choice.

The problem we have is that the API implementation has a real weakness
when both inputs are zero (see [1]) and branch optimizations don't
help much, we still end up with too many 'ucomisd'. But with
favourable data (not too many zeros) and a good branch optimization,
the API might be faster though.

This is exactly what I meant early in the first thread, see [2]; it's
quite impossible to find an instruction sequence that will get all
paths faster regardless of the data...
But zeros are rather frequent and the intrinsic is still 2x faster
with poor predictions.

So, if I had to choose (but I'm not a Reviewer), I'd probably be to
incorporate this intrinsic unless we find a realistic example showing
an important regression.

Bernard

[1] http://hg.openjdk.java.net/jdk/jdk/file/3997614d4834/src/java.base/share/classes/java/lang/Math.java#l1467
[2] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-January/032564.html