logic in Math.nextAfter for handling -0.0 input

Deneau, Tom tom.deneau at amd.com
Fri Jun 27 23:40:35 UTC 2014


That's what I was doing below.  Is the problem that we are "inlining everything" on the hsail backend?

-- Tom

-----Original Message-----
From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] 
Sent: Friday, June 27, 2014 6:39 PM
To: Deneau, Tom
Cc: graal-dev at openjdk.java.net
Subject: Re: logic in Math.nextAfter for handling -0.0 input

Just call it.  A call to the original method stays a real call to that method and doesn't get substituted.

tom

On Jun 27, 2014, at 4:35 PM, Deneau, Tom <tom.deneau at amd.com> wrote:

> Pinging, since I never saw an answer to this.
> 
> I thought there was some way to substitute for a method and still call 
> the original method without getting into a recursive call...
> 
> (The original problem below is resolved but need this kind of solution for a different reason).
> 
> -- Tom
> 
> 
> -----Original Message-----
> From: Deneau, Tom
> Sent: Monday, June 23, 2014 3:43 PM
> To: Deneau, Tom; 'graal-dev at openjdk.java.net'
> Subject: RE: logic in Math.nextAfter for handling -0.0 input
> 
> Related to this... 
> Should I be able to work around this with the following hsail MethodSubstitution?
> When I try this, I get a StackOverflowError...
> 
> -- Tom
> 
> @ClassSubstitution(java.lang.Math.class)
> public class HSAILMathSubstitutions {
>     ...
>    @MethodSubstitution
>    public static double nextAfter(double x, double direction) {
>        // work around special case of -0.0
>        double xx = (x == -0.0 ? 0.0 : x);
>        return Math.nextAfter(xx, direction);
>    }
> }
> 
> 
> 
> 
> -----Original Message-----
> From: Deneau, Tom
> Sent: Monday, June 23, 2014 3:34 PM
> To: 'graal-dev at openjdk.java.net'
> Subject: logic in Math.nextAfter for handling -0.0 input
> 
> The JDK method Math.nextAfter contains the logic shown below to handle 
> an input of -0.0
> 
> When the graal compiler compiles this for the hsail backend, it makes the reasonable assumption that "start + 0.0d" can be reduced to "start" which is a problem for this algorithm.
> 
> From what I could tell, c2 or graal for amd64 backend do not do this optimization and so get the right answer for -0.0 input.  How do they know not to do this optimization?
> 
> 
>        } else {        // start > direction or start < direction
>            // Add +0.0 to get rid of a -0.0 (+0.0 + -0.0 => +0.0)
>            // then bitwise convert start to integer.
>            long transducer = Double.doubleToRawLongBits(start + 0.0d);         <==============
> 
>            if (direction > start) { // Calculate next greater value
>                transducer = transducer + (transducer >= 0L ? 1L:-1L);
>            } else  { // Calculate next lesser value
>                  ....
> 
> -- Tom



More information about the graal-dev mailing list