PPC64: Poor StrictMath performance due to non-optimized compilation (original) (raw)

joe darcy joe.darcy at oracle.com
Tue Nov 22 00:42:10 UTC 2016

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/showbug.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

More information about the core-libs-dev mailing list