Request for review (S): 6833879 Assigning positive zero is ignored when old value is negative zero

Changpeng Fang Changpeng.Fang at Sun.COM
Wed Apr 29 14:26:22 PDT 2009


Don't know why this email was bounced back. Resend! -- Changpeng

On 04/29/09 12:47, Changpeng Fang wrote:
> On 04/29/09 12:32, Tom Rodriguez wrote:
>> BTW, you can use TypeF::ZERO and TypeD::ZERO to check for positive 
>> zero constants instead of breaking them down, as in phase->type(f) == 
>> TypeF::ZERO.  I don't think this fix is sufficient.  It has the same 
>> problem for "if (v == -0.0f) v == -0.0f" and as you said originally 
>> it won't work right dynamically either.
>
> Is -0.0f  TypeF::ZERO?.  Yes, this is just a partial fix.  "if (v == 
> -0.0f) v == -0.0f" case should be fine with this partial fix because
> **tf->_f==0.0 still applies for -0.0f.
>
> Handling dynamic issue is too expensive in the sense that we disables most float and double cases .
>
>
> Thanks.
>
> Changpeng
>
> **


> ****
>
>> tom
>>
>> On Apr 29, 2009, at 10:59 AM, Changpeng Fang wrote:
>>
>>> http://cr.openjdk.java.net/~cfang/6833879/webrev.00/
>>>
>>> Problem:
>>> For the following case:
>>> public static double normalize(float v) {
>>>       if (v == 0.0f) v = 0.0f;
>>>       return v;
>>> }
>>> If -0.0 is passed, 0.0 is expected to be returned (it is the case 
>>> for the interpreter). However,
>>> PhiNode::Identity optimized away the "if and assignment" statement 
>>> and the server vm
>>> return -0.0.
>>>
>>> Proposed Solution:
>>> Don't perform this kind of identity optimization if either true path 
>>> or false path is constant
>>> 0.0 or (-0.0)
>>>
>>> Open Issue:
>>> When the true path or false path is not constant, it may still be 
>>> 0.0 (-0.0) at run time.
>>> Do we have to turn off this identity optimization completely  for 
>>> float  and double (except
>>> for constant non-zeros)?
>>> Tests: Passed the test case in the CR report.
>>>
>>> Thanks,
>>>
>>> Changpeng
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20090429/cf6a6179/attachment.html 


More information about the hotspot-compiler-dev mailing list