RFR(M): 8171244: PPC64: Make interpreter's math entries consistent with C1 and C2 and support FMA

[Lindenmaier, Goetz]

Hi Martin, 

thanks for investigation the other rule.
All fine. 

Best regards,
  Goetz.

> -----Original Message-----
> From: Doerr, Martin
> Sent: Donnerstag, 15. Dezember 2016 16:32
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; 'hotspot-compiler-
> dev at openjdk.java.net' <hotspot-compiler-dev at openjdk.java.net>
> Subject: RE: RFR(M): 8171244: PPC64: Make interpreter's math entries
> consistent with C1 and C2 and support FMA
> 
> Hi,
> 
> thank you very much for reviewing.
> 
> I have added reviewer information and made minor changes.
> The as_FloatRegister usages are replaced, now.
> I have also removed the predicate(UseFMA). They don't make any sense
> because the matcher doesn't have a choice.
> The decision whether they should be used is done before, of course.
> 
> New webrev is here:
> http://cr.openjdk.java.net/~mdoerr/8171244_PPC64_fma/webrev.01/
> 
> I have also tried the match rules proposed by Götz, but they didn't match.
> Reason seems to be that the Fma nodes have a control input.
> 
> Vladimir, you can push it if you're ok with it. Thank you very much for
> sponsoring.
> 
> Best regards,
> Martin
> 
> 
> -----Original Message-----
> From: Lindenmaier, Goetz
> Sent: Donnerstag, 15. Dezember 2016 12:00
> To: Doerr, Martin <martin.doerr at sap.com>; 'hotspot-compiler-
> dev at openjdk.java.net' <hotspot-compiler-dev at openjdk.java.net>
> Subject: RE: RFR(M): 8171244: PPC64: Make interpreter's math entries
> consistent with C1 and C2 and support FMA
> 
> Hi Martin,
> 
> thanks for doing this change.
> 
> I looked a while at the change in the ad file:
> Would it make sense to add match rules with outermost Neg?
> 
>  // -src1 * src2 - src3 = -(src1*src2+src3)  instruct mnaddF_reg_reg(regF dst,
> regF src1, regF src2, regF src3) %{
>    predicate(UseFMA);
>    match(Set dst (FmaF (NegF src3) (Binary (NegF src1) src2)));
>    match(Set dst (FmaF (NegF src3) (Binary src1 (NegF src2))));
> + match(Set dst Neg(FmaF src3 (Binary src1 src2)));
> 
> Besides that the change looks good.  Please run it through our nightly tests.
> Maybe you could use $reg$$FloatRegister as in the other rules.
> 
> Best regards,
>   Goetz.
> 
> > -----Original Message-----
> > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-
> > bounces at openjdk.java.net] On Behalf Of Doerr, Martin
> > Sent: Mittwoch, 14. Dezember 2016 17:59
> > To: 'hotspot-compiler-dev at openjdk.java.net' <hotspot-compiler-
> > dev at openjdk.java.net>
> > Subject: RFR(M): 8171244: PPC64: Make interpreter's math entries
> > consistent with C1 and C2 and support FMA
> >
> > Hi,
> >
> >
> >
> > as discussed in [1], floating point computations should produce
> > consistent results regardless of whether the Java code gets
> > interpreted or is compiled by any JIT-compiler.
> >
> > In addition, JDK9 introduced new floating point multiply-accumulate
> > intrinsics which are currently missing on PPC64.
> >
> >
> >
> > Webrev is here:
> >
> > http://cr.openjdk.java.net/~mdoerr/8171244_PPC64_fma/webrev.00/
> > <http://cr.openjdk.java.net/~mdoerr/8171244_PPC64_fma/webrev.00/>
> >
> >
> >
> > Note: The current version of the change removes the function
> > "math_entry_available" from shared code which was only used by PPC.
> >
> > I can either leave it there or ask somebody from Oracle to sponsor.
> >
> >
> >
> > Please review.
> >
> >
> >
> > Best regards,
> >
> > Martin
> >
> >
> >
> >
> >
> > [1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-
> > December/025073.html <http://mail.openjdk.java.net/pipermail/hotspot-
> > compiler-dev/2016-December/025073.html>
> >
> >