[cfe-dev] CLang and ISO C math functions

Thu Sep 1 02:34:28 PDT 2016

Thanks James and Hal,

I hadn’t thought of ‘-fno-builtin’ (blush), and as you say the “as if” rule is fine.  With ‘-fno-builtin’ the behaviour is as I had expected.  And you are right, for testing the math functions in the library I need to use this.

Regarding James’ points below:

Bullet 2, in v3.8.0 the call was being elided when ‘-fno-math-errno’ was not specified, and this appears to have been changed in v3.9.0 (which I see just got tagged :) ) which does not elide the call.

It was this change that drew my attention to the problem.  Sorry for putting this on CFE-Dev, I incorrectly thought that this was a Front-End optimisation issue.  If I have further thoughts on this I will start a new thread on LLVM-Dev.

All the best,

            MartinO

From: James Molloy [mailto:james at jamesmolloy.co.uk] 
Sent: 01 September 2016 09:48
To: Martin.ORiordan at movidius.com; Hal Finkel <hfinkel at anl.gov>
Cc: Clang Dev <cfe-dev at lists.llvm.org>
Subject: Re: [cfe-dev] CLang and ISO C math functions

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 <mailto:cfe-dev at lists.llvm.org> > wrote:

Thanks Hal,

From: Hal Finkel [mailto:hfinkel at anl.gov <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 <mailto: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/cbd11019/attachment.html>