[9] 8154122: Intrinsify fused mac operations on x86

[Vladimir Kozlov]

Change subject to match JBS.

Tests passed. I'm pushing these changes.

Thanks,
Vladimir

On 8/25/16 2:45 PM, Vladimir Kozlov wrote:
> 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.
>>>
>>>