Using a java port of fdlibm on the hsail backend

[Deneau, Tom]

Thanks for the response, Joe.

We might experiment with the existing Java port that I mentioned, just to have something to
use in the hsail backend while we are waiting for the official java port that you will do for Java 9.

So far I have only used the sin routine from this java port and in the small
amount of testing I did, the result was within 1 ulp of the standard java.lang.Math.sin result.
(this was whether I ran the java version on the cpu or on the hsail gpu).

-- Tom

> -----Original Message-----
> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
> Sent: Thursday, May 08, 2014 5:17 PM
> To: Joe Darcy
> Cc: Azeem Jiva; Tom Rodriguez; Douglas Simon; graal-
> dev at openjdk.java.net; Deneau, Tom
> Subject: Re: Using a java port of fdlibm on the hsail backend
> 
> 
> On May 8, 2014, at 12:03 PM, Joe Darcy <joe.darcy at oracle.com> wrote:
> 
> > Hello,
> >
> > The C code in fdlibm is written in a very particular style. I don't
> trust many people to do the port; I happen to be one of the people I
> trust to do this ;-)
> >
> > Reviewing someone else's port of this code would be an effort on par
> with doing the port myself, so I prefer to do the port myself. I intend
> to do this port in 9 (this time for real!).
> 
> Hear! Hear!  Thank you, I really appreciate this.  If there is anything
> I can help with, let me know.
> 
> > Having this code in Java will reduce our exposure to C compiler
> vagaries when upgrade compilers or port Java to new platforms. (The C
> code in fdlibm uses long / double aliasing and thus runs afoul of most
> optimizers.)
> >
> > HTH,
> >
> > -Joe
> >
> > On 05/08/2014 06:23 AM, Azeem Jiva wrote:
> >> Joe and I have talked about this on and off for quite some time.
> I've CCed him to see what his current thoughts are on this.
> >>
> >>
> >> On May 7, 2014, at 8:41 PM, Tom Rodriguez <tom.rodriguez at oracle.com>
> wrote:
> >>
> >>> On May 7, 2014, at 7:35 PM, Christian Thalinger
> <christian.thalinger at oracle.com> wrote:
> >>>
> >>>> On May 7, 2014, at 10:43 AM, Doug Simon <doug.simon at oracle.com>
> wrote:
> >>>>
> >>>>> Given that it was contributed under an OCA, I don't see why we
> couldn't use. However, otherwise with more legal knowledge can confirm
> that.
> >>>>>
> >>>>> I wonder why there was no interest shown in this contribution on
> the hotspot-dev mailing list. It makes me wonder if the Java port is
> really 100% compliant.
> >>>> This was a long time ago and I'm also curious why there was no
> interest.
> >>> From the hotspot side fdlibm is a solved problem.  Replacing it with
> a Java version might be better in some ways but it perturbs the universe
> without much clear upside.  It also introduces maintenance concerns
> since fdlibm is fairly broadly used but the Java version probably isn't.
> >>>
> >>> Joe Darcy would be the one to ask about the quality of the Java
> port.  If it were ever adopted by the JDK he would also likely be the
> one to do it.
> >>>
> >>> tom
> >>>
> >>>> Anyway, I filed a tracking bug because we didn't have one:
> >>>>
> >>>> [#JDK-8042716] Java port of fdlibm 5.3 to java.lang.StrictMath -
> Java Bug System
> >>>>
> >>>>> -Doug
> >>>>>
> >>>>> On May 7, 2014, at 8:56 PM, Deneau, Tom <tom.deneau at amd.com>
> wrote:
> >>>>>
> >>>>>> Sending to Azeem representing the hotspot team and to the graal
> team...
> >>>>>>
> >>>>>> On the hsail backend, we would like to implement the various
> java.lang.Math routines and we need a solution that is completely hsail,
> since we can't call out to any  host C routines.  An easy solution for
> us would be to use a java implementation of java.lang.Math.  I saw this
> mail back in the hotspot-dev archives describing a port of FDLIBM to
> Java which looked promising.
> >>>>>>
> >>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2009-
> August/001992.html
> >>>>>>
> >>>>>> I have tried the sin() routine out of this port in the hsail
> backend and it seems to work well functionally and performance-wise.
> >>>>>>
> >>>>>> Is there any problem with using this code as part of the graal
> project as @MethodSubstitutions?
> >>>>>>
> >>>>>> -- Tom Deneau
> >>>>>>
> >