[cfe-dev] fast-math, clang-6+ and floating point exceptions

via cfe-dev cfe-dev at lists.llvm.org
Wed Jul 31 06:07:08 PDT 2019

> -----Original Message-----
> From: cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] On Behalf Of
> Nicholas Devenish via cfe-dev
> Sent: Tuesday, July 30, 2019 6:28 PM
> To: cfe-dev at lists.llvm.org
> Subject: [cfe-dev] fast-math, clang-6+ and floating point exceptions
> I'm working on scientific code, that  explicitly catches and crashes
> on floating point exceptions (I've seen several such projects in the
> past in the scientific domain do this). *Everything* is compiled with
> -ffast-math and -O3. However, we've got this code in a module:
>     float w = std::log(x);
>     if (x > 3) {
>         w -= std::log(w);
>     }
> Godbolt: https://godbolt.org/z/yvGqjl
> Basically, if I'm reading the assembly output properly, it looks like
> clang > 6 optimizes this into assuming that the second log is almost
> always run (not unreasonably), always calls log twice, and eliminates
> the branch. However, in our code, the second log causes an FPE which
> jumps to a crash handler.
> My questions are:
> - Am I correct in my interpretation of what's going on here?
> - Is this a reasonable thing for clang to do - it's not implied by any
> of the cases on
> https://clang.llvm.org/docs/UsersManual.html#cmdoption-ffast-math ,
> although to be fair that does say it's a non-inclusive list. GCC
> _doesn't_ seem to make this transform, though obviously that doesn't
> mean that it's a bad one

I'm far from an expert, but we've run into this kind of thing, and
basically (a) LLVM assumes there are no exceptions, (b) it is willing
to speculate FP operations sometimes; this combo can go boom.

> - Can I prevent this from happening, even with -ffast-math enabled?

We do the equivalent of `-mllvm -speculate-one-expensive-inst=false`
and it helps.

> - Is this sort of configuration sensible or insane?

In the golden land of perfect understanding of FP exceptions, it would
be controllable in a more complete and principled way.  LLVM is a long
way off from that.

> Thanks,
> Nick
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

More information about the cfe-dev mailing list