x86 Intrinsics for fma in Math Library

Vladimir Kozlov vladimir.kozlov at oracle.com
Thu Aug 25 21:45:01 UTC 2016


Looks good! I will run tests and will push if they passed.

Thanks,
Vladimir

On 8/25/16 10:51 AM, Deshpande, Vivek R wrote:
> 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.
>>
>>


More information about the hotspot-compiler-dev mailing list