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

[Vitaly Davidovich]

>
> I did not get the question. If you look on usage of immD0/immF0 it is
> replaced with 0 (or G0) value which we can easy embed into instructions. It
> is not easy to use 0x80000000 such way. It will need to be loaded into
> register in separate instruction.


You sort of answered my question :).  For instructions that can take an
immediate of that size (i.e. 0x8000...), I thought it wasn't being done to
minimize instruction encoding size, but loading the value into a register
in a separate instruction is also valid.  My overall question was why -0.0
was not embedded, and I think you've answered that.

Thanks

On Thu, Mar 12, 2015 at 12:05 PM, Vladimir Kozlov <
vladimir.kozlov at oracle.com> wrote:

> On 3/12/15 8:28 AM, Vitaly Davidovich wrote:
>
>> Hi Zoltan,
>>
>> Is -0.0{f,d} not replaced with an immediate because the immediate then
>> increases instruction size? Just curious ...
>>
>
> I did not get the question. If you look on usage of immD0/immF0 it is
> replaced with 0 (or G0) value which we can easy embed into instructions. It
> is not easy to use 0x80000000 such way. It will need to be loaded into
> register in separate instruction.
>
> But I think -0. is rare so it should not be a problem.
>
> Regards,
> Vladimir
>
>
>> Thanks
>>
>> On Thu, Mar 12, 2015 at 8:43 AM, Zoltán Majó <zoltan.majo at oracle.com
>> <mailto:zoltan.majo at oracle.com>> wrote:
>>
>>     Hi,
>>
>>
>>     please review the following small patch.
>>
>>     Bug: https://bugs.openjdk.java.net/__browse/JDK-8074869 <
>> 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 <http://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/ <
>> 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/6778c2dd/attachment.html>