[cfe-dev] CLang and ISO C math functions

[James Molloy via cfe-dev]

Hi Martin,

I'm having a little difficulty understanding this:

> I would expect this behaviour if ‘-ffast-math -fno-math-errno’ was
selected, but it isn’t, and I think that this is an invalid optimisation.

There are two optimizations going on:
  1. Constant folding of exp() results.
  2. Elision of exp() calls.

I would expect (1) to be valid even in full IEEE compliance mode. I would
expect (2) to be valid with -fno-math-errno - that is, assume that errno
doesn't exist. This is implied by -ffast-math.

(1) is valid in all modes because of the "as-if" rule - the return value is
as-if the function were called. The function has well defined behaviour, so
we don't actually need to call it to get the result. (2) would also be
valid in all modes as far as I understand it, because on successful return
exp() does *not* change errno. exp(1.0) is well-defined and succeeds, so
errno doesn't change. It seems to me that clang has regressed in
performance here in 3.9 unless there's a subtlety that I'm missing
(probable).

It sounds to me like you're attempting to test your math library. If you're
doing this, you probably want -fno-builtin which informs the compiler not
to assume the library calls are well defined. With this flag, no constant
folding (or elision) will be done which I presume is what you want.

Cheers,

James

On Thu, 1 Sep 2016 at 09:08 Martin J. O'Riordan via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> Thanks Hal,
>
>
>
> *From:* Hal Finkel [mailto:hfinkel at anl.gov]
> *Sent:* 01 September 2016 01:48
>
> I would expect this behaviour if ‘-ffast-math -fno-math-errno’ was
> selected, but it isn’t, and I think that this is an invalid optimisation.
> It also means that some of my math functional tests are not reporting
> honestly (this only happens when the argument(s) are constants).  Also, on
> our architecture, ‘double’ is FP32,
>
> Does Clang for your target emit C-language "double" types as "double" at
> the IR level? If so, that's wrong. "double" at the IR level is assumed to
> be an IEEE double-precision number. All of the constant folding will do the
> wrong thing on your target if this is what is happening.
>
>
>
> No, I have:
>
>
>
>       DoubleFormat = &llvm::APFloat::IEEEsingle;
>
>
>
> set in my ‘TargetInfo’, and the IR shows ‘f32’.  But it is the elision of
> the tests when I am not using ‘-ffast-math’ that I think is wrong, the
> tests are not present; I’m quite happy with this behaviour when ‘
> -ffast-math’ is used.  In the ‘foo’ example the calls to ‘foo’ are
> retained and the tests are present; it is only when I rename ‘foo’ to ‘exp’
> or some other math function that this happens.
>
>
>
> With ‘-fno-math-errno’ it can be assumed that the math functions have no
> other side-effects, and in combination with ‘-ffast-math’ the reduction
> to the optimal ‘return 0’ is perfect.  But neither of these options are
> selected.
>
>
>
> I downloaded the official v3.8.0 distribution for X86 from the LLVM
> website and tried that, and got the same behaviour, it’s not particular to
> my out-of-tree changes.  With v3.9.0 RC3 the calls to the math functions
> are no longer elided, but the tests still are.
>
>
>
> and it is probable that the compiler is using the host platform’s
> implementation which is FP64 for evaluating the test expressions,
>
> Yes, that's right. See ConstantFoldScalarCall in LLVM's
> lib/Analysis/ConstantFolding.cpp. We're obviously aware this can cause
> issues when cross compiling. If you'd like to discuss this behavior, you
> should do so on llvm-dev. We might want to make this more configurable than
> it currently is.
>
> I don’t have any issue with the constant-folding, just the elision of the
> tests.  I assume that the special handling of the C math functions is
> happening in CLang rather than LLVM, but I don’t generally look much at the
> semantic analysis code so I am not as familiar with it.  If the math
> library semantic issues are LLVM then I should post this on LLVM-Dev, but I
> think that this is more likely front-end issue - no?
>
>
>
>             MartinO
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160901/8142f7f7/attachment.html>