similar to: RFC: SIMD math-function library

Hi everyone, I think that everyone is on the same page. We'll put together a patch for review. One remaining question: There seem two potential homes for this library: parallel_libs and compiler-rt. Opinions on where the vectorized math functions should live? My inclination is to target it for the new parallel_libs project, in part because I feel like compiler-rt has too many things grouped

Is it possible to see the source code of the open-sourced SVML? The diff file does not include the library. I searched the Internet but I could not find. Regards, Naoki Shibata On 2016/07/15 13:55, Tian, Xinmin wrote: > Naoki, > > Intel is planning open-source SVML library (most of them if it not 100%), 6 functions of SVML are open sourced for GCC and LLVM already. But, Intel SVML

Hi all, Okay, the point is whether Intel will publish the source code for their SVML. If Intel will make SVML open-source, there would be not much advantage in incorporating SLEEF into LLVM, since it would be also fairly easy to port SVML to other architectures. If Intel will not open-source SVML, then there could be advantage in using SLEEF for x86 by inlining the functions. Is it possible

I should keep quiet and leave well enough alone, but playing devil's advocate for a moment - I see you didn't bundle this with compiler-rt, which I guess is good? In the end what was the reasoning for that? Do you see this being sufficiently independent and running a different development track that it made sense? 1) Why rename C files to C++ (consistency?) 2) It seems your

Why is there any motivation to bundle it with unrelated stuff at all? What's the benefit? If it's just to prop up the existence of parallel_libs, then I don't think that makes sense.. Should we move llvm loop optimizations over to parallel_libs as well? If this is just a bikeshed argument, of course chandler will get his way and nobody else matters.. Hopefully, the decision is driven

----- Original Message ----- > From: "C Bergström" <cbergstrom at pathscale.com> > To: "Chandler Carruth" <chandlerc at gmail.com> > Cc: "Hal Finkel" <hfinkel at anl.gov>, "llvm-dev" <llvm-dev at lists.llvm.org>, "Matt Masten" <matt.masten at intel.com>, > "Naoki Shibata" <shibatch.sf.net at

So for us we use SLEEF to actually implement the libcalls (LLVM intrinsics) that LLVM by default would generate - and since SLEEF has highly optimal 8-wide pow, optimized for AVX and AVX2, we really want to use that. So we would not see 4/8 libcalls and instead see 1 call to something that lights up the ymm registers. I guess the problem then is that the default expectation is that pow would be

On 07/02/2018 04:33 PM, Saito, Hideki wrote: > >   > > >It may not be a full solution for the problems you're trying to solve > >   > > If we are inventing a new solution, I’d like it also to solve OpenMP > declare simd legalization issue. If a small extension of existing scheme > > works for mathlib only, I’m happy to take that and discuss OpenMP >

RFC: A proposal for vectorizing loops with calls to math functions using SVML (short vector math library). ========= Overview ========= Very simply, SVML (Intel short vector math library) functions are vector variants of scalar math functions that take vector arguments, apply an operation to each element, and store the result in a vector register. These vector variants can be generated by the

Hi Sanjay, For sincos calls, I’m currently just going through isTriviallyVectorizable(), which was good enough to get things working so that I could test the translation. I don’t see why this cannot be changed to use addVectorizableFunctionsFromVecLib(). The other functions that I’m working with are already vectorized using the loop pragma. Those include sin, cos, exp, log, and pow. From: Sanjay

Hi all, I am submitting the following RFC [1] to re-implement -fveclib via OpenMP constructs. The RFC was discussed during a round table at the last LLVM developer meeting, and presented during the BoF [2]. The proposal is published on Phabricator, for the purpose of keeping track of the comments, and it now ready for a review from a wider audience after being polished by Hal Finkel and Hideki

Hi, If you're interested, include/bits/random.tcc:3312 (std::generate_canonical()). I wish I could just point people at libc++, but that's outside of my control. As for fixing the library, that horse bolted some time ago. Cheers, James On Mon, 4 Apr 2016 at 18:50 Stephen Canon <scanon at apple.com> wrote: > That sounds like a library issue that qualifies as “somewhat

Hi, cross-compiling LLVM on the ppc64 architecture fails with: make[1]: *** No rule to make target `../build/llvm-r204075/BuildTools/Debug+Asserts/bin/llvm-tblgen', needed by `../build/llvm-r204075/lib/IR/Debug+Asserts/Intrinsics.gen.tmp'. Stop. make[1]: *** Waiting for unfinished jobs.... this fails for me for r204075 (today) and r203443. Configuration details: $LLVMPATH/configure

Illustrative Example: clang -fveclib=SVML -O3 svml.c -mavx #include <math.h> void foo(double *a, int N){ int i; #pragma clang loop vectorize_width(8) for (i=0;i<N;i++){ a[i] = sin(i); } } Currently, this results in a call to <8 x double> __svml_sin8(<8 x double>) after the vectorizer. This is 8-element SVML sin() called with 8-element argument. On the surface,

I've tried to do: clang++ -O3 -march=native -mtune=native \ -Rpass=loop-vectorize,slp-vectorize -Rpass-missed=loop-vectorize,slp-vectorize -Rpass-analysis=loop-vectorize,slp-vectorize \ -ffast-math -ffp-model=fast -ffp-exception-behavior=ignore -ffp-contract=fast \ -c -o vec.o vec.cc But I've got no feedback. -- Alexandre Bique

Hi, Clang is currently unable to constant fold calls to math.h functions such as logl(), expl() etc. The problem is that APFloat doesn't have these functions, so Clang is forced to rely on the host math library. Because long double isn't portable, we only ever query the host math library for double or float results. I can see three methods for allowing constant folding for types that

Ashutosh, Thanks for the repy. Related earlier topic on this appears in the review of the SVML patch (@mmasten). Adding few names from there. https://reviews.llvm.org/D19544 There, I see Hal's review comment "let's start only with the directly-legal calls". Apparently, what we have right now in the trunk is "not legal enough". I'll work on the patch to stop

Adding to Ashutosh's comments, We are also interested in making LLVM generate vector math library calls that are available with glibc (version > 2.22). reference: https://sourceware.org/glibc/wiki/libmvec Using the example case given in the reference, we found there are 2 vector versions for "sin" (4 X double) with same VF namely _ZGVcN4v_sin (avx) version and _ZGVdN4v_sin

I am filing this as a bug report so it doesn't get lost. Martyn -----FW: <XFMail.000616094624.plummer@iarc.fr>----- Date: Fri, 16 Jun 2000 09:46:24 +0200 (CEST) Sender: owner-r-devel@stat.math.ethz.ch From: Martyn Plummer <plummer@iarc.fr> To: Naoki Takebayashi <ntakebay@bio.indiana.edu> Subject: RE: [Rd] [PATCH] ./configure fails to recognize alphapca56 (R-1. Cc:

It may not be a full solution for the problems you're trying to solve, but I don't know why adding to include/llvm/CodeGen/RuntimeLibcalls.def is a problem in itself. Certainly, it's a mess that could be organized, especially so we're not repeating everything for each data type as we do right now. So yes, I think that would allow us to remove the VecLib mappings because we are