search for: ofast

...Clang's performance was mixed. It optimized the expression template > code just as well as the code that unrolled the expressions by hand, > but that may be because it only did a mediocre job of optimizing the > unrolled versions. GCC had similar performance issues until I used > -Ofast. I could not find a similar option for Clang, partly because I > could not find a complete list of Clang compiler options. You can see > a list of all of the compiler options that I used at -Ofast enables unsafe optimizations that can change the results produced by floating-point operation...

Duncan, What is the situation with -Ofast in dragonegg 3.4? Are we now enabling all of the same optimizations for that case as are done in clang when it is passed -Ofast? Thanks in advance for any clarification. Jack

On Wed, Oct 12, 2016 at 10:53 AM, Hal Finkel <hfinkel at anl.gov> wrote: > I don't think that Clang/LLVM uses it by default on x86_64. If you're using -Ofast, however, that would explain it. I recommend looking at -O3 vs -O0 and make sure those are the same. -Ofast enables -ffast-math, which can legitimately cause differences. > The following tests pass at "-O3" and "-O3 -ffp-contract=on" compared with FP_ABSTOLERANCE=1e-5 agains...

On 14 October 2016 at 15:50, Sebastian Pop <sebpop.llvm at gmail.com> wrote: > These 3 tests are passing with the following configurations: > -O3 -ffp-contract=off > -O3 -ffp-contract=on > -O0 -ffp-contract=off > -O0 -ffp-contract=on > > They are not passing at: > -Ofast -ffp-contract=on > -Ofast -ffp-contract=off Let's separate completely FP-contract and fast-math. They're different things and need different solutions. > if(TEST_SUITE_USES_FAST_MATH) > add_definitions(-DFP_ABSTOLERANCE=1e0) > else() > add_definitions(-DFP_ABSTOLERANCE...

...ormance was mixed. It optimized the expression template >> code just as well as the code that unrolled the expressions by hand, >> but that may be because it only did a mediocre job of optimizing the >> unrolled versions. GCC had similar performance issues until I used >> -Ofast. I could not find a similar option for Clang, partly because I >> could not find a complete list of Clang compiler options. You can see >> a list of all of the compiler options that I used at > > -Ofast enables unsafe optimizations that can change the results produced by floati...

...lues to be at or near 0. > > Oh, if the output is stuck at -32768, then it's likely some NaNs crept > in. The first thing to check is whether the problem is on the encoder > side or the decoder side (when if you use a 1.1 encoder with a 1.2 > decoder and vice versa). In general, -Ofast is not IEEE-compliant when > it comes to NaN, so libopus has to work around that non-compliance. > The encoder in my setup is always the one in chrome m64. I'm pretty sure thats 1.2 and I'm not sure but I think they don't compile with -Ofast. The decoder which gets stuck at -3276...

...s.de>, "Clang Dev" <cfe-dev at lists.llvm.org>, "nd" <nd at arm.com>, "Abe Skolnik" >> <a.skolnik at samsung.com> >> Sent: Friday, October 14, 2016 10:36:12 AM >> Subject: Re: [test-suite] making polybench/symm succeed with "-Ofast" and "-ffp-contract=on" >> >> On 14 October 2016 at 15:50, Sebastian Pop <sebpop.llvm at gmail.com> >> wrote: >> > These 3 tests are passing with the following configurations: >> > -O3 -ffp-contract=off >> > -O3 -ffp-contract=on >...

...ench/linear-algebra/solvers/gramschmidt, FP_ABSTOLERANCE=1e0 >> What should be a good relative tolerance to set for these two tests? > > What's the minimum relative tolerance that you need for them to pass? Setting FP_ABSTOLERANCE=1e-5, the two tests are passing when compiled with -Ofast for the following relative tolerance: polybench/linear-algebra/kernels/symm, FP_TOLERANCE=1e-10 polybench/linear-algebra/solvers/gramschmidt, FP_TOLERANCE=1e5 gramschmidt passes validation against reference output, symm does not pass validation against reference output: I have opened a bug for th...

...gt;, "nd" <nd at arm.com>, "Abe Skolnik" <a.skolnik at samsung.com>, >> "Sebastian Pop" <sebpop.llvm at gmail.com> >> Sent: Wednesday, October 12, 2016 9:16:39 AM >> Subject: Re: [test-suite] making polybench/symm succeed with "-Ofast" and "-ffp-contract=on" >> >> On 12 October 2016 at 15:05, Hal Finkel <hfinkel at anl.gov> wrote: >> > This is something we need to understand. No, there's not always an >> > error bar. With FMA formation and without non-IEEE-compliant >>...

...I think it is valid to skip those tests in the test-suite when a fast math > flag combination is used (after making sure there is no easy way to make the test more robust). > I would add a "TEST_SUITE_FAST_MATH" variable in the cmake build (possibly scanning CFLAGS for -ffast-math/-Ofast > to determine the default value) and then adding if(NOT TEST_SUITE_FAST_MATH) ... endif() around the benchmark. I accept Matthias` proposal, and I propose that the above be used for wherever "really fixing" the FP problems with a test is beyond a reasonable effort+time level. T...

On Thu, Oct 20, 2016 at 11:12 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 20 October 2016 at 16:05, Sebastian Pop <sebpop.llvm at gmail.com> wrote: >> Setting FP_ABSTOLERANCE=1e-5, the two tests are passing >> when compiled with -Ofast for the following relative tolerance: >> >> polybench/linear-algebra/kernels/symm, FP_TOLERANCE=1e-10 >> polybench/linear-algebra/solvers/gramschmidt, FP_TOLERANCE=1e5 > > I'm confused. Is this 1e-5 or 1e5? The test passes for a relative tolerance of 100,000.

On 12 October 2016 at 15:05, Hal Finkel <hfinkel at anl.gov> wrote: > This is something we need to understand. No, there's not always an error bar. With FMA formation and without non-IEEE-compliant optimizations (i.e. fast-math), the optimized answer should be identical to the non-optimized answer. What about architectures that this is never respected, like Darwin? In the general

...acc += B[k][j] * A[k][i]; } C[i][j] = beta * C[i][j] + alpha * A[i][i] * B[i][j] + alpha * acc; } } Compiling this kernel with __attribute__((optnone)) and outputing the contents of the C[][] array does not match the reference output. Furthermore, compiling this kernel at -Ofast and comparing against -O0 only passes for FP_ABSTOLERANCE=10. All the 10 other polybench tests that I have transformed to check FP are passing at FP_ABSTOLERANCE=1e-5 (and most likely they could pass at an even more reduced tolerance.) The symm benchmark seems to accumulate all the errors as it is...

...t braunis.de>, "Clang Dev" <cfe-dev at lists.llvm.org>, "nd" <nd at arm.com>, "Abe Skolnik" <a.skolnik at samsung.com> > Sent: Friday, October 7, 2016 7:56:53 PM > Subject: Re: [llvm-dev] [test-suite] making the test-suite succeed with "-Ofast" and "-ffp-contract=on" > > ----- Original Message ----- > > From: "Sebastian Pop" <sebpop.llvm at gmail.com> > > To: "Renato Golin" <renato.golin at linaro.org> > > Cc: "Kristof Beyls" <Kristof.Beyls at arm.com&gt...

...near 0. > > Oh, if the output is stuck at -32768, then it's likely some NaNs crept > in. The first thing to check is whether the problem is on the encoder > side or the decoder side (when if you use a 1.1 encoder with a 1.2 > decoder and vice versa). In general, -Ofast is not IEEE-compliant when > it comes to NaN, so libopus has to work around that non-compliance. > > > The encoder in my setup is always the one in chrome m64. I'm pretty sure > thats 1.2 and I'm not sure but I think they don't compile with -Ofast. > The decoder...

...isunderstood: you would be ok changing the > reference output to exactly match the output of "-O0 -ffp-contract=off". No, that's not at all what I said. Matching identical outputs to FP tests makes no sense because there's *always* an error bar. The output of O0, O1, O2, O3, Ofast, Os, Oz should all be within the boundaries of an average and its associated error bar. By understanding what's the *expected* output and its associated error range we can accurately predict what will be the correct reference_output and the tolerance for each individual test. Your solution 2...

On 12 October 2016 at 17:09, Hal Finkel <hfinkel at anl.gov> wrote: >> I accept Matthias` proposal, and I propose that the above be used for >> wherever "really fixing" >> the FP problems with a test is beyond a reasonable effort+time level. >> This email is to check >> acceptance [or lack thereof] of the above. > > This makes sense to me. I

Hi, I would like to provide a summary of the different proposals on how to fix the test-suite to make it succeed when specifying extra CFLAGS "-Ofast" and "-ffp-contract=on". I would like to expose the issue and proposed ways to fix it to other potential reviewers that could provide extra feedback. We also need to decide which proposal (or combination of) to implement and commit. Proposal 1: https://reviews.llvm.org/D25277 modi...

On 12 October 2016 at 13:04, Sebastian Pop <sebpop.llvm at gmail.com> wrote: > The other problem is the reference output does not match > at "-O0 -ffp-contract=off". It might be that the reference output was recorded > at "-O3 -ffp-contract=off". I think that this hides either a compiler > bug or a test bug. Ah, yes! You mentioned before and I forgot to

...uot;Clang Dev" <cfe-dev at lists.llvm.org>, "nd" <nd at arm.com>, "Abe Skolnik" >>> <a.skolnik at samsung.com> >>> Sent: Tuesday, October 11, 2016 6:33:43 AM >>> Subject: Re: [test-suite] making polybench/symm succeed with "-Ofast" and "-ffp-contract=on" >>> >>> On 11 October 2016 at 12:15, Sebastian Pop <sebpop.llvm at gmail.com> >>> wrote: >>> >> 1. Only test the non-FP-contracted output >>> > >>> > Yes, this is what I'm doing. >...