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

[Doerr, Martin]

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>
> 
>