PPC64: Poor StrictMath performance due to non-optimized compilation

[joe darcy]

Hello,


On 11/21/2016 4:34 PM, Gustavo Romero wrote:
> Hi Chris,
>
> On 17-11-2016 19:48, Chris Plummer wrote:
>>> The fdlibm code relies on aliasing a two-element array of int with a double to do bit-level reads and writes of floating-point values. As I understand it, the C spec allows compilers to assume
>>> values of different types don't overlap in memory. The compilation environment has to be configured in such a way that the C compiler disables code generation and optimization techniques that would
>>> run afoul of these fdlibm coding practices.
>> This is the strict aliasing issue right? It's a long standing problem with fdlibm that kept getting worse as gcc got smarter. IIRC, compiling with -fno-strict-aliasing fixes it, but it's been more
>> than 12 years since I last dealt with fdlibm and compiler aliasing issues.
> I've tested with -O3 and -fno-strict-aliasing as you suggested but it did not
> fix the fp precision issue on PPC64.
>
> After finding that -fno-expensive-optimizations solved the problem, we narrowed
> down the problem to the FMA: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78386
>
>

That makes sense; an FMA will by its nature provide different results 
than separate (unfused) multiple and add operations. While the 
polynomials used in fdlibm would benefit performance-wise from implicit 
replacement with FMA, such a replacement would violate the StrictMath 
contract. Therefore, if FDLIBM is left in C sources, it must be compiled 
in such a way that FMA is *not* substituted for multiply and add.

Thanks,

-Joe