[9] RFR(S): 8074869: C2 code generator can replace -0.0f with +0.0f on Linux

[Vitaly Davidovich]

Hi Zoltan,

Is -0.0{f,d} not replaced with an immediate because the immediate then
increases instruction size? Just curious ...

Thanks

On Thu, Mar 12, 2015 at 8:43 AM, Zoltán Majó <zoltan.majo at oracle.com> wrote:

> Hi,
>
>
> please review the following small patch.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8074869
>
>
> Problem: On Linux, the C2 code generator can replace the value -0.0f with
> +0.0f (and also the value -0.0d with +0.0d). The reason is that in some
> *.ad files both the value -0.0f and +0.0f is treated as being +0.0f and can
> therefore be replaced with an immediate +0.0f embedded into an instruction.
>
> For example, in the sparc.ad file, the 'fpclass' function is used to
> decide if a float node's content is +0.0:
>
> predicate((n->getf() == 0) && (fpclass(n->getf()) == FP_PZERO));
>
> On Solaris, 'fpclass' returns FP_PZERO if the parameter is +0.0f and
> FP_NZERO if the parameter is -0.0f. As a result, +0.0f and -0.0f are
> distinguished by the compiler.
>
> On Linux, however, 'fpclass' is not available and therefore 'fpclassify'
> is used. 'fpclassify' does not distinguish between ±0.0f, it returns
> FP_ZERO for both +0.0f and -0.0f.
>
>
> Solution: Instead of 'fpclass', use cast float->int and double->long to
> check if value is +0.0f and +0.0d, respectively. This logic is already use
> on some architectures, for example on x86_32 and on x86_64.
>
> As 'fpclass' is not used any more, remove its declarations from
> globalDefintions_*. The include of ieeefp.h must be kept as we rely on some
> other functionality from this header on solaris.
>
>
> Webrev: http://cr.openjdk.java.net/~zmajo/8074869/webrev.00/
>
>
> Testing:
> - JPRT testing on all supported platforms (does *not* include aarch64 and
> ppc64)
>
> - manual testing on aarch64:
>
> All DaCapo benchmarks with the small input size. I used the default JVM
> flags and tested the VM w/ and w/o the fix. All benchmarks pass except
> eclipse. For eclipse, the same Java-level failure appears both w/ and w/o
> the fix, so I think the problem with eclipse is not due to these changes.
>
> I also tested with the "-Xcomp -XX:-TieredCompilation -server" flags.
> Eclipse fails in this case as well. Additionally, tradebeans and tradesoap
> fail with a Java-level failure. As the failure happens also with both
> builds (w/ and w/o the fix), I don't think the problem is caused by these
> changes either.
>
> - no testing on ppc64: I don't have access to a ppc64 machine. Could
> somebody with access to a ppc64 machine please build and test the VM with
> this patch (and then maybe confirm that it works)?
>
>
> Thank you and best regards,
>
>
> Zoltan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20150312/4ebc6c86/attachment-0001.html>