<div dir="ltr">Hi Zoltan,<div><br></div><div>Is -0.0{f,d} not replaced with an immediate because the immediate then increases instruction size? Just curious ...</div><div><br></div><div>Thanks</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 12, 2015 at 8:43 AM, Zoltán Majó <span dir="ltr"><<a href="mailto:zoltan.majo@oracle.com" target="_blank">zoltan.majo@oracle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
<br>
please review the following small patch.<br>
<br>
Bug: <a href="https://bugs.openjdk.java.net/browse/JDK-8074869" target="_blank">https://bugs.openjdk.java.net/<u></u>browse/JDK-8074869</a><br>
<br>
<br>
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.<br>
<br>
For example, in the <a href="http://sparc.ad" target="_blank">sparc.ad</a> file, the 'fpclass' function is used to decide if a float node's content is +0.0:<br>
<br>
predicate((n->getf() == 0) && (fpclass(n->getf()) == FP_PZERO));<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
Webrev: <a href="http://cr.openjdk.java.net/~zmajo/8074869/webrev.00/" target="_blank">http://cr.openjdk.java.net/~<u></u>zmajo/8074869/webrev.00/</a><br>
<br>
<br>
Testing:<br>
- JPRT testing on all supported platforms (does *not* include aarch64 and ppc64)<br>
<br>
- manual testing on aarch64:<br>
<br>
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.<br>
<br>
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.<br>
<br>
- 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)?<br>
<br>
<br>
Thank you and best regards,<br>
<br>
<br>
Zoltan<br>
<br>
</blockquote></div><br></div>