search for: ffinit

Hello, when building code with -Ofast -ffinite-math-only -ffast-math, clang generates calls to "finite" variants of math functions. This has been the source of a fair amount of issues in a "normal", non-JIT pipeline, which seem to have been fixed over time - a simple fix being recompiling the target app against the new gli...

...the same example, with the same bitcode input, runs from outside the container, it does not find this symbol, likely because the host (in my case Arch, I think you need a glibc-2.31 at least for that behaviour to be visible)'s glibc symbols became versioned. Removing either the -fmath-errno or -ffinite-math-only flag for the clang cpp -> bitcode invocation in build.sh fixes the issue (at the expense of potentially slower code). <http://www.jcelerier.name> Thanks for the hint, sadly it's not possible to take the address of __log_finite : what happens is that you call the function e....

...milattice of sensible relations: > A > S > I > N > A > F > Meaning that 'A' implies all the others, 'S' implies 'I' and 'N', etc. > Why does it make sense for S to imply I and N? GCC's -fno-signed-zeros flag doesn't seem to imply -ffinite-math-only, among other things. The concept of negative zero isn't inherently linked with the concepts of infinity or NaN. > > It might make sense to change the S, I, and N options to be some kind of > finite > option with levels 3, 2, and 1 respectively. F and A could be kept &gt...

...; linker -- a few people are working on an initial implementation of that at > the moment. > > -- Lang. > > On Mon, Oct 5, 2020 at 12:52 AM Jean-Michaël Celerier via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hello, >> when building code with -Ofast -ffinite-math-only -ffast-math, clang >> generates calls to "finite" variants of math functions. >> >> This has been the source of a fair amount of issues in a "normal", >> non-JIT pipeline, which seem to have been fixed over time - a simple fix >> being re...

...; result is undefined. > > no signed zeros (S) > - The optimizer is allowed to not distinguish between -0 and +0 for the > purposes of optimizations. > > Ok, I checked LLVM CodeGen's existing -enable-no-infs-fp-math and -enable-no-nans-fp-math flags, and GCC's -ffinite-math-only flag, and they all say they apply to results as well as arguments. Do you have a good reason for varying from existing practice here? > The primary example I was trying to simplify with that change was x * 0 ==> 0. It can be performed if you assume NIS inputs, or NS inputs and N...

...-math so they can, e.g., use FMA instructions in their > > publishes. > > But this is a side issue, and I'm rather sorry I mentioned SPEC at > > all. > > This is really an issue of internal and external consistency. > > Yes, but Steve is right: -ffast-math implies -ffinite-math-only, which > means that we assume no NaNs. I understand that people use -ffast-math to > get vectorized reductions (just getting aggressive FMAs only requires > -ffp-contract=fast), but this, unfortunately, is also a matter of internal > consistency :( > > -Hal > > &...

...he > result is undefined. > > no signed zeros (S) > - The optimizer is allowed to not distinguish between -0 and +0 for the > purposes of optimizations. > Ok, I checked LLVM CodeGen's existing -enable-no-infs-fp-math and -enable-no-nans-fp-math flags, and GCC's -ffinite-math-only flag, and they all say they apply to results as well as arguments. Do you have a good reason for varying from existing practice here? Phrasing these from the perspective of the optimizer is a little confusing here. Also, "The optimizer is allowed to [not care about X]" read li...

https://aur.archlinux.org/packages/nbdkit#comment-938282 ----- Forwarded message from notify at aur.archlinux.org ----- Date: Sat, 14 Oct 2023 12:40:02 +0000 Subject: AUR Comment for nbdkit dreieck [1] added the following comment to nbdkit [2]: `check()` fails for me, too: ``` [...] make check-TESTS make[3]: Entering directory '/tmp/makepkg/build/nbdkit/src/nbdkit-1.36.0/server'

Hi, We are interesting in expanding some vector operations directly in the IR form as constants https://reviews.llvm.org/D33406, for example: _mm256_cmp_ps("any input", "any input", _CMP_TRUE_UQ) should produce -1, -1, -1, ... vector, but for some values for example "1.00 -nan" if FPU exceptions were enabled this operation triggers the exception. Here is the question:

...efines *-fno-signed-zeros:* > "Allow optimizations for floating point arithmetic that ignore the > signedness of zero. IEEE arithmetic specifies the behavior of distinct > +0.0 and -0.0 values, which then prohibits simplification of expressions > such as x+0.0 or 0.0*x (even with *-ffinite-math-only*). This option > implies that the sign of a zero result isn't significant." > > I'll revise my description to also mention that the sign of a zero result > isn't significant. > Ok, I see what you're saying here now. > > Also, even when you do...

On Fri, 2014-09-26 at 12:09 -0400, Stephen Canon wrote: > > On Sep 26, 2014, at 11:59 AM, Tim Northover <t.p.northover at gmail.com> wrote: > > > >> I know it's part of test-suite/external, but this constant fold code has > >> been around 5+ years. Was the bug lying dormant all this time, only visible > >> on PPC, or something else? > > >

...user education, but that's much better than producing subtly-wrong results. We have a pass-feedback mechanism, I think it would be very useful for compiling with -Rpass-missed=loop-vectorize and/or -Rpass-analysis=loop-vectorize helpfully informed users that compiling with -ffast-math and/or -ffinite-math-only and -fno-signed-zeros would allow the loop to be vectorized for the targeted hardware. -Hal > > cheers, > --renato > -- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory

...lso, once we get the current set of things resolved, I think it would be useful to test running with: -- -O3, LTO (-O4 or -flto), -- -fslp-vectorize, -fslp-vectorize-aggressive (which are actually separate optimizations) -- -ffast-math (if you can do floating point with tolerances, or at least -ffinite-math-only), -fno-math-errno (and there are obviously a whole bunch of non-default code-generation and target options). Is it feasible to set up runs with different flags? > Once there's a bug in the compiler, there's > really no limit in the number of failing tests that can be &gt...

...estion to be related, consider the flags of 'comiss, ucomiss, etc.' : ZPC unordered 111 greater than 000 less than 001 equal 100 Try the following C program with gcc, first with no options and then with --ffinite-math-only (or --ffast-math) ----------- #define STR(X) #X #define CMP(X) if (X) { printf(STR(X) " true\n"); } else { printf(STR(X) " false\n"); } int main(int argc, char** argv) { float a = 0.f/0.f; // generate a NaN float b = 1; // any finite CMP(a!=a);...

...I'm not too familiar with this option, but I recommend that 'all' turn on the 'F' bit for all FP instructinos, default do so when following the pragma, and off never doing so. This option should still be passed to the backend. (Optional) I propose adding the below flags: -ffinite-math-only Allow optimizations to assume that floating point arguments and results are NaNs or +/-Inf. This may produce incorrect results, and so should be used with care. This would set the 'I' and 'N' bits on all generated floating point instructions. -fno-signed-zeros...

...math so they can, e.g., use FMA instructions in their > > publishes. > > But this is a side issue, and I'm rather sorry I mentioned SPEC at > > all. > > This is really an issue of internal and external consistency. > > Yes, but Steve is right: -ffast-math implies -ffinite-math-only, which means that we assume no NaNs. I understand that people use -ffast-math to get vectorized reductions (just getting aggressive FMAs only requires -ffp-contract=fast), but this, unfortunately, is also a matter of internal consistency :( Hi Hal, Sure. Well, if the consensus is that...

...gcc-6.2.0/gcc/Optimize-Options.html#Optimize-Options <https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Optimize-Options.html#Optimize-Options> > > -ffp-contract=style > -ffast-math > -fno-math-errno > -funsafe-math-optimizations > -fassociative-math > -freciprocal-math > -ffinite-math-only > -fno-signed-zeros > -fno-trapping-math > -frounding-math > -fsignaling-nans > -fsingle-precision-constant > > etc, and the relevant negations of these options. We can't predict how customers will choose to chain these together, so I think the LLVM optimizer an...

...hings resolved, I think it > would be useful to test running with: > > -- -O3, LTO (-O4 or -flto), > -- -fslp-vectorize, -fslp-vectorize-aggressive (which are actually > separate optimizations) > -- -ffast-math (if you can do floating point with tolerances, or at > least -ffinite-math-only), -fno-math-errno > (and there are obviously a whole bunch of non-default > code-generation and target options). > > Is it feasible to set up runs with different flags? > > > Once there's a bug in the compiler, there's > > really no limit in the num...

...hings resolved, I think it > would be useful to test running with: > > -- -O3, LTO (-O4 or -flto), > -- -fslp-vectorize, -fslp-vectorize-aggressive (which are actually > separate optimizations) > -- -ffast-math (if you can do floating point with tolerances, or at > least -ffinite-math-only), -fno-math-errno > (and there are obviously a whole bunch of non-default > code-generation and target options). > > Is it feasible to set up runs with different flags? > > > Once there's a bug in the compiler, there's > > really no limit in the num...

I am happy to report that current llvm/llvm-gcc-4.2 svn builds all of xplor-nih (a complex mix of c, c++ and fortran) with -O3 -fPIC -msse4 -ffast-math. A single fortran file exposes PR3376 which is triggered by -O3 -ffinite-math-only. The resulting build of xplor-nih completely passes its testsuite and compares very well to the same build against gcc trunk for gcc 4.4 in terms of execution time. gcc 4.4 llvm-gcc-4.2 svn xplo 68.5205s 64.7649s xplor-python...