Investigate clang's -frounding-math

[mglisse]

Issue Details

Not directly an issue, but... It used to be that clang didn't support -frounding-math. However, we have enough protection through inline asm that things seemed to work fine. Recent versions of clang implement #pragma fenv and -frounding-math seems to turn it on globally. I see 2 things we should investigate

• short term: does mixing -frounding-math with our protection cause overhead? (IIUC we don't add -frounding-math for clang like we do for gcc, but some users might)
• longer term, experiment with the pragma on clang (or with -frounding-math, but the pragma is more localized) to see if it can generate better code than what we currently have. Old experiments with MSVC were disappointing, but that doesn't prove much.

Environment

• Compiler: clang
• Release or debug mode: Release
• Specific flags used (if any): -frounding-math
• CGAL version: master

[lrineau]

Here is the change: https://reviews.llvm.org/D62731#change-Qs7eGduOQs42. It seems to have been introduced in clang 10.0.0.

• the option is present in https://releases.llvm.org/10.0.0/tools/clang/docs/UsersManual.html, but
• it was not in https://releases.llvm.org/9.0.0/tools/clang/docs/UsersManual.html.

The experiments we tried in the past about the pragma were not successful, because the effects of pragma with C++ templates was not the expected ones.

[mglisse]

The experiments we tried in the past about the pragma were not successful, because the effects of pragma with C++ templates was not the expected ones.

But that was with MSVC or Intel, right? At least with very basic tests (certainly nothing exhaustive though), clang seemed to do something sensible with templates. On the other hand, llvm seems to optimize essentially nothing when rounded operations are involved. Even converting 2 to double is done at runtime... And it seems to disable inlining. On the benchmark Triangulation_3/simple_2.cpp with 100000 points, -frounding-math increases the running time from .34 to .41. So for now I would recommend that clang users avoid -frounding-math.

[lrineau]

The experiments we tried in the past about the pragma were not successful, because the effects of pragma with C++ templates was not the expected ones.

But that was with MSVC or Intel, right? At least with very basic tests (certainly nothing exhaustive though), clang seemed to do something sensible with templates. On the other hand, llvm seems to optimize essentially nothing when rounded operations are involved. Even converting 2 to double is done at runtime... And it seems to disable inlining. On the benchmark Triangulation_3/simple_2.cpp with 100000 points, -frounding-math increases the running time from .34 to .41. So for now I would recommend that clang users avoid -frounding-math.

Maybe we should consider removing -frounding-math with gcc as well, and apply workarounds. That might also speeds up computations.

[mglisse]

IIRC with gcc -frounding-math doesn't cause much slowdown for CGAL (in large part because the option doesn't protect against much). On the other hand, it doesn't do much and we would probably be about as safe without it.

[lrineau]

IIRC with gcc -frounding-math doesn't cause much slowdown for CGAL (in large part because the option doesn't protect against much). On the other hand, it doesn't do much and we would probably be about as safe without it.

That is right. The real challenge would be to try -funsafe-math-optimizations or -ffast-math with gcc.

[mglisse]

Adding -ffast-math at link time brings in an object file that sets the processor mode to flush denormals to 0, irrespective of rounding modes. That doesn't seem compatible with intervals. So you would first need to put that back to normal later in the initialization. Other than that, intervals should be fine I think. I am less confident about static filters, the bounds rely on the code the way it is written, and even changing (x+y)+z to x+(y+z) could change the required bound for the filter.