similar to: [LLVMdev] [cfe-dev] C++ Expression Template Benchmarks for GCC/Clang/Intel/PGI/MSVC

On Jun 15, 2012, at 9:16 AM, Douglas Gregor wrote: > On Jun 14, 2012, at 3:54 PM, Walter Landry wrote: >> Hello Everyone, >> >> I thought you might be interested in some C++ expression template >> benchmarks I have done. >> >> http://www.wlandry.net/Projects/FTensor#Benchmarks >> >> Clang's performance was mixed. It optimized the

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

On Fri, Oct 14, 2016 at 10:50 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Renato Golin" <renato.golin at linaro.org> >> To: "Sebastian Pop" <sebpop.llvm at gmail.com> >> Cc: "Hal Finkel" <hfinkel at anl.gov>, "Sebastian Paul Pop" <s.pop at samsung.com>,

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

On 10/11/2016 at 4:15 PM, Matthias Braun wrote: > I don't find it surprising that some applications do not work properly with -ffast-math and I think we > have to accept that fact. 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

On Wed, Oct 12, 2016 at 10:28 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Renato Golin" <renato.golin at linaro.org> >> To: "Hal Finkel" <hfinkel at anl.gov> >> Cc: "Sebastian Paul Pop" <s.pop at samsung.com>, "llvm-dev" <llvm-dev at lists.llvm.org>, "Matthias

Hi all, While reviewing a recent clang documentation change, I became aware of an issue with the way that clang is handling FP denormals. There is currently some support for variations in the way denormals are handled, but it isn't consistent across architectures and generally feels kind of half-baked. I'd like to discuss possible solutions to this problem. First, there is a clang

----- Original Message ----- > From: "Hal Finkel via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Sebastian Pop" <sebpop.llvm at gmail.com> > Cc: "Sebastian Paul Pop" <s.pop at samsung.com>, "llvm-dev" <llvm-dev at lists.llvm.org>, "Matthias Braun" > <matze at braunis.de>, "Clang Dev" <cfe-dev

Hi, I'm reading "http://llvm.org/docs/Vectorizers.html" and have few question. Hope someone has answers on it. The Loop Vectorizer can vectorize code that becomes a sequence of scalar instructions that scatter/gathers memory. ( http://llvm.org/docs/Vectorizers.html#scatter-gather) int foo(int *A, int *B, int n, int k) { for (int i = 0; i < n; ++i) A[i*7] += B[i*k]; } I

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 glibc. - https://bugs.llvm.org/show_bug.cgi?id=44842 -

Hi Robert, Can you ping the code owners about these patches. It might be good to write a separate email per code owner and cc the appropriate -commits list. Thanks, Tom On Wed, Apr 02, 2014 at 06:16:44PM +0400, Robert Khasanov wrote: > Hi Tom, > > I would like to nominate the following patches to be backported to 3.4.1 > > Clang: > 1. r204742 - Zinovy Nis <zinovy.nis at

On Fri, Oct 14, 2016 at 6:10 PM, Hal Finkel <hfinkel at anl.gov> wrote: >> polybench/linear-algebra/kernels/symm, FP_ABSTOLERANCE=1e1 >> polybench/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

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

On Thu, Feb 22, 2018 at 9:53 PM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > On 02/22/2018 09:34 PM, Stepan Salenikovich wrote: > > Its unexpected because the decoder continues to output all samples > > of -32768 even when the microphone input is silence or near silence, so > > I would expect the decoded values to be at or near 0. > > Oh, if the output is

In order to vectorize code like this LLVM needs to prove that “A[i*7]” does not wrap in the address space. It fails to do so and so LLVM doesn’t vectorize this loop even if we try to force it. The following loop will be vectorized if we force it: int foo(int * A, int * B, int n, int k) { for (int i = 0; i < 1024; ++i) A[i] += B[i*k]; } So will this loop: int foo(int * restrict A, int

Hello, Right now I am just using a Generator to look for symbols in my process (which links dynamically against libc / libm). It seems to have no trouble finding every other libc / libm / libc++ / ... symbol so I assumed that it was not necessary to specifically link against libm where these __finite symbols reside: $ nm -D /usr/lib/libm.so.6 | grep finite 0000000000050540 T

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'

Dear all, In the process of investigating a performance difference between Clang & GCC when both compile the same non-toolchain program while using the "same"* compiler flags, I have found something that may be worth changing in Clang, developed a patch, and confirmed that the patch has its intended effect. *: "same" in quotes b/c the essence of the problem is that the

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 12 October 2016 at 14:26, Sebastian Pop <sebpop.llvm at gmail.com> wrote: > Correct me if I misunderstood: 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,