x86 Intrinsics for fma in Math Library

[Deshpande, Vivek R]

Hi Vladimir

I have updated the hotspot webrev as per your suggestions.
Could you please review it.
The webrev is at this location:
http://cr.openjdk.java.net/~vdeshpande/FMA/8154122/hotspot/webrev.02/

Regards,
Vivek


-----Original Message-----
From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] 
Sent: Tuesday, August 16, 2016 7:35 PM
To: Deshpande, Vivek R; Andrew Haley; hotspot-compiler-dev at openjdk.java.net
Cc: Viswanathan, Sandhya
Subject: Re: x86 Intrinsics for fma in Math Library

Hi, Vivek

You can't use UseFMA in shared code if you define it only in globals_x86.hpp. It should be in globals.hpp

I would suggest to have new MacroAssembler methods fmad() and fmaf() instead of calling vfmadd231 directly.

Pass it 4 registers and if dst == op3 don't do move. It will simplify code (in .ad files pass dst 2 times). Use movflt() and movdbl() macro instructions.

The arguments order for this methods should be the same as for java
fma() method (currently it is confusing since you shuffle them for vfmadd231).

I would also guard UseFMA setting in vm_version with UseSSE >= 2 (needed for 32-bit VM). There are a lot of code which check it when we work with float values to keep them in XMM registers.

In templateInterpreterGenerator_x86_<>.cpp files use movflt for fmaF to load float arguments.

In .ad files add comment into format // a * b + c

subnode.cpp - move TOP checks before #ifndef. And we don't do indention of #ifdef.

Thanks,
Vladimir

On 8/15/16 1:29 PM, Deshpande, Vivek R wrote:
> Hi All
>
> I have updated the patch with suggested changes.
> Please find the webrevs at this location:
> http://cr.openjdk.java.net/~vdeshpande/FMA/8154122/hotspot/webrev.01/
> and
> http://cr.openjdk.java.net/~vdeshpande/FMA/8154122/jdk/webrev.01/
>
> Regards,
> Vivek
>
> -----Original Message-----
> From: Andrew Haley [mailto:aph at redhat.com]
> Sent: Wednesday, August 03, 2016 3:03 PM
> To: Deshpande, Vivek R; Vladimir Kozlov; 
> hotspot-compiler-dev at openjdk.java.net
> Subject: Re: x86 Intrinsics for fma in Math Library
>
> On 03/08/16 22:37, Deshpande, Vivek R wrote:
>> I can do that along with rest of the suggested changes in the patch.
>> Could you please also give me some more information on using #ifdef 
>> __STDC_IEC_559__
>
> Maybe do this:
>
> //------------------------------Value---------------------------------
> --------- const Type* FmaDNode::Value(PhaseGVN* phase) const { #ifndef 
> __STDC_IEC_559__
>   return Type::DOUBLE;
> #else
>   const Type *t1 = phase->type(in(1));
>   if (t1 == Type::TOP) return Type::TOP;
>   if (t1->base() != Type::DoubleCon) return Type::DOUBLE;
>   const Type *t2 = phase->type(in(2));
>   if (t2 == Type::TOP) return Type::TOP;
>   if (t2->base() != Type::DoubleCon) return Type::DOUBLE;
>   const Type *t3 = phase->type(in(3));
>   if (t3 == Type::TOP) return Type::TOP;
>   if (t3->base() != Type::DoubleCon) return Type::DOUBLE;
>   double d1 = t1->getd();
>   double d2 = t2->getd();
>   double d3 = t3->getd();
>   return TypeD::make(fma(d1, d2, d3)); #endif }
>
> Perhaps this is too simple, and you should return TOP if any of the operands are of type TOP; I'm not sure.
>
> But the point is that if __STDC_IEC_559__ is defined, then you are guaranteed that the libm fma() is the same as Java fma().
>
> Andrew.
>
>