search for: fp_contract

Hi, clang deals with #pragma STDC FP_CONTRACT and updates the setting of FPOptions::fp_contract, but how is this made use of in the back end? Is there some way to find out, for any given pair of floating-point operations, whether they can be contracted into one (according to their local pragma settings), or is this not yet implemented? Al --...

...ic problem here relates to the default settings for FP contraction, e.g. fused multiply-add. At -O2 and higher, GCC defaults FP contraction to "fast", i.e. always on. I`m not suggesting that Clang/LLVM/both need to do the same, since Clang+LLVM has good support for "#pragma STDC FP_CONTRACT". If we keep Clang`s default for FP contraction at "on" [which really means "according to the pragma"] but change the default value of the _pragma_ [currently off] to on at -O3, then Clang will be more competitive with GCC at high optimization settings without resorting...

...viour Sebastian encountered is dealt with before this going live, or we'd be breaking too many test-suites and reverting and reapplying too often. But I'm certainly in favour of the plan to make it on/fast by default. > If you were to change your source file to: > > #pragma STDC FP_CONTRACT ON > int foo(float a, float b, float c) { return a*b+c; } I wasn't aware you needed the pragma for -ffp-contract=on. I assumed it would enable on all fp-math that the standard allowed (thus maybe needing some annotation on the operations). I thought that the pragma was to avoid using the c...

...rren.ristow at sony.com> > Sent: Friday, November 18, 2016 10:37:08 AM > Subject: Re: what does -ffp-contract=fast allow? > fp-contract is confusing, so let me try to summarize that and the > underlying implementation: > 1. -ffp-contract=on means honor the compiler's default FP_CONTRACT > setting or any FP_CONTRACT pragmas in the source. Currently, clang > defaults to "OFF". The shouting is not an accident; this is not the > same as the flag's "off" setting. This is described nicely here: > https://reviews.llvm.org/D24481 > If we set "o...

...cause I think it's reasonable for a user who cares about precision and FP exceptions to still want FMA, which theoretically is more precise. I think not (a) because clang doesn't usually generate the fmuladd intrinsic with -ffp-contract=fast. On the other hand, if the code also contained an FP_CONTRACT pragma around doSomethingPrecise() I think clang should do (a). Supporting the FP_CONTRACT case is the point of the D72820 patch. But let's make this more interesting. Suppose I compile with "-O2 -fp-model=strict -ffp-contract=fast -fno-honor-nans -fno-honor-infinities -fno-signed-zeros&...

On Wed, May 23, 2018 at 12:19 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > On 05/23/2018 11:06 AM, Hubert Tong via llvm-dev wrote: > > Hi Ulrich, > > I am interested in knowing if the current proposals also take into account > the FP_CONTRACT pragma > > > We should already do this (we turn relevant operations into the > @llvm.fmuladd. when FP_CONTRACT is set to on during IR generation). > I am not sure we have the same interpretation of what the FP_CONTRACT pragma does. Subclause 6.5 paragraph 8 of C11 implies (for exampl...

On 03/15/2017 11:39 AM, Stephen Canon wrote: > We should default to pragma STDC FP_CONTRACT ON, not ‘fast’. > > ‘on’ is the most aggressive mode that conforms to C11. ‘fast’ should > be opt-in (like ‘fast-math’ is). Why? Other compilers default to 'fast', and 'on' does not play well with C++ code (where inlining is really important, and so the statement bounda...

...it returns NAN because 0 * INF = NAN. >>> >>> 1. I used aarch64 as the example target, but this is not target-dependent (as long as the target has FMA). >>> >>> 2. This is *not* -ffast-math...or is it? The C standard only shows on/off settings for the associated FP_CONTRACT pragma. >>> >>> 3. AFAIK, clang has no documentation for -ffp-contract: >>> http://clang.llvm.org/docs/UsersManual.html >>> >>> 4. GCC says: >>> https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Optimize-Options.html#Optimize-Options >>> &qu...

A little background: The fmuladd intrinsic was introduced to support the FP_CONTRACT pragma in C. llvm.fmuladd.* is generated by clang when it sees an expression of the form 'a * b + c' within a single source statement. If you want to opportunistically form FMA target instructions my inclination would be to skip llvm.fmuladd.* and just form them from a*b+c expressions at...

On 05/23/2018 11:06 AM, Hubert Tong via llvm-dev wrote: > Hi Ulrich, > > I am interested in knowing if the current proposals also take into > account the FP_CONTRACT pragma We should already do this (we turn relevant operations into the @llvm.fmuladd. when FP_CONTRACT is set to on during IR generation). > and the ability to implement options that imply a specific value for > the FLT_EVAL_METHOD macro. What do you mean by this?  -Hal > > Additio...

...don't reassociate. With reassociation to FMA, it returns NAN because 0 * INF = NAN. 1. I used aarch64 as the example target, but this is not target-dependent (as long as the target has FMA). 2. This is *not* -ffast-math...or is it? The C standard only shows on/off settings for the associated FP_CONTRACT pragma. 3. AFAIK, clang has no documentation for -ffp-contract: http://clang.llvm.org/docs/UsersManual.html 4. GCC says: https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Optimize-Options.html#Optimize-Options "-ffp-contract=fast enables floating-point expression contraction such as forming of fu...

...n smaller granularity than module). But now that I think more about, we should be able to turn a user function attribute into FMF in the front-end which is the most flexible. >>> >>> I agree, a FMF is the way to go and we can then control it with the pragma. We can use the STDC FP_CONTRACT pragma for contraction; >> >> Just to confirm, do you mean to introduce a “fast” option to the pragma, e.g.: >> >> #pragma STDC FP_CONTRACT FAST > > That's a good point. If we don't add something like this, then we'd be able to turn the fast mode off wit...

...contract=fast on smaller granularity than module). But now that I think more about, we should be able to turn a user function attribute into FMF in the front-end which is the most flexible. > > I agree, a FMF is the way to go and we can then control it with the pragma. We can use the STDC FP_CONTRACT pragma for contraction; Just to confirm, do you mean to introduce a “fast” option to the pragma, e.g.: #pragma STDC FP_CONTRACT FAST Thanks, Adam > I also think that having a "fast math" pragma is also a good idea (the fact that we can currently only specify fast-math settings on a...

...one), the performance gain is too large > to be ignored by default. I highly recommend that we continue to enable > FMA instruction-generation by default (as is the current practice, not > only here, but in most vendor compilers with which I am familiar). We > should also implement the FP_CONTRACT pragma, but that is another > matter. The caveat I would add to this is that, when I tried enabling FMA-by-default on an ARM target, I saw a large number of testcases in the LLVM test suite that either failed their output comparisons, crashed, or failed to terminate (!!!). That seems pretty sc...

...ou know what you're doing. The key point is that LLVM (currently) has no notion of statement boundaries, so it would fuse the operations in this function: float foo(float accum, float lhs, float rhs) { float product = lhs * rhs; return accum + product; } This isn't allowed even under FP_CONTRACT=on (the multiply and add do not occur within a single expression), so LLVM can't in good conscience enable these optimisations by default. Cheers. Tim.

...) is size_t, defined in <stddef.h> (and other headers)." SPIR defines size_t as a unsized unsigned integer and as such cannot be known until the SPIR binary is lowered to the device. At that time, SPIR is known and as such can be lowered correctly to its type. *** Hal Finkel: Handling FP_CONTRACT *** *****Comment: The current specification provides a mechanism for handling FP_CONTRACT, but does so only at the module level. After much debate, we have adopted and implemented a way of handling FP_CONTRACT in clang/LLVM through the llvm.fmuladd...

...y point is that LLVM (currently) has no notion of statement > boundaries, so it would fuse the operations in this function: > > float foo(float accum, float lhs, float rhs) { > float product = lhs * rhs; > return accum + product; > } > > This isn't allowed even under FP_CONTRACT=on (the multiply and add do > not occur within a single expression), so LLVM can't in good > conscience enable these optimisations by default. > > Cheers. > > Tim. > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pi...

...y... > > Are Richard's and Hal's suggestions different parts of the same suggestion? > Is the "fast math" state part of the AST and therefore available to > AST consumers that way? I wouldn't guess that since the -ffast-math option > would be compilation wide. fp_contract provides a very similar set of language features, with both a global flag and a #pragma that can be used at either global or local scope to control semantics thenceforth. We handle that in the AST by storing FPOptions on individual arithmetic expressions, and IRGen propagates that to the individua...

...ost* always a better one), the performance gain is too large to be ignored by default. I highly recommend that we continue to enable FMA instruction-generation by default (as is the current practice, not only here, but in most vendor compilers with which I am familiar). We should also implement the FP_CONTRACT pragma, but that is another matter. -Hal > > > Anyone more knowledgable about FP than me have any ideas? > > > --Owen > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://ll...

> "-ffp-contract=fast" is needed Correct - clang is different than gcc, icc, msvc, xlc, etc. on this. Still haven't seen any explanation for how this is better though... http://llvm.org/bugs/show_bug.cgi?id=17188 http://llvm.org/bugs/show_bug.cgi?id=17211 On Wed, Dec 18, 2013 at 6:02 AM, Tim Northover <t.p.northover at gmail.com>wrote: > > I believe that's the