search for: sleef

...and Technology. I and Hal Finkel would like to jointly propose to add my vectorized math library to LLVM. The library has been available as public domain software for years, I am going to double-license the library if necessary. ******** Below is a proposal to add my vectorized math library, SLEEF [1], for evaluating elementary functions (trigonometry, log, exp, etc.) to LLVM. The library can be used directly, or can be targeted by an autovectorization infrastructure. Patches to tie SLEEF into LLVM's autovectorizer have been developed by Hal Finkel as part of the bgclang project (whi...

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 to ask the person in charge what exactly Intel is going to contribute? Naoki Sh...

...M > already. But, Intel SVML is x86 centric (SSE2, SSSE3, SSE4.1, > SSE4.2, AVX, AVX2 ....}. Personally, I am not sure if it would be > fairly easy to port SVML to other architectures. SVML library team > may provide a better answer, I will double check with them. > > Given that SLEEF supports many different architectures, I think it > has a value for LLVM, at least before all porting is done for SVML > library to other architectures by LLVM community after Intel open > sourced it. > > Thanks, > Xinmin > > -----Original Message----- > From: Naoki Shi...

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...

...ric (SSE2, SSSE3, SSE4.1, >> > SSE4.2, AVX, AVX2 ....}. Personally, I am not sure if it would be >> > fairly easy to port SVML to other architectures. SVML library team >> > may provide a better answer, I will double check with them. >> > >> > Given that SLEEF supports many different architectures, I think it >> > has a value for LLVM, at least before all porting is done for SVML >> > library to other architectures by LLVM community after Intel open >> > sourced it. >> > >> > Thanks, >> > Xinmin >&...

...urced for GCC and LLVM already. But, Intel SVML is x86 centric (SSE2, SSSE3, SSE4.1, SSE4.2, AVX, AVX2 ....}. Personally, I am not sure if it would be fairly easy to port SVML to other architectures. SVML library team may provide a better answer, I will double check with them. > > Given that SLEEF supports many different architectures, I think it has a value for LLVM, at least before all porting is done for SVML library to other architectures by LLVM community after Intel open sourced it. > > Thanks, > Xinmin

...the web The deadline to apply for a EuroLLVM Student Travel Grant [closes today, February 26th at 5pm PST](http://lists.llvm.org/pipermail/llvm-dev/2018-February/121385.html). LLVM 6.0.0-rc3 [as been tagged](http://lists.llvm.org/pipermail/llvm-dev/2018-February/121366.html). Version 3.2 of the [SLEEF](http://sleef.org/) vectorized math library has been released. This includes performance improvements, a new CMake-based build system, and more. ## On the mailing lists * Anastasia Stulova is looking for feedback on a [proposal to add OpenCL C++ suport](http://lists.llvm.org/pipermail/cfe-dev/20...

...s like I was expecting - nice! Thanks for the help! Cheers, -Neil. On Fri, Jul 17, 2020 at 12:09 PM Florian Hahn <florian_hahn at apple.com> wrote: > > > On 16 Jul 2020, at 19:54, Neil Henning via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > 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. > > > Right, the way vector versions of library functions are accessed by the &gt...

...ar > modular design, repo with the same name it had before, works > independent of any compiler, clearly defined what it is and who is > working on it as well as the goals.. To be clear, I think the community should decide on the name. Using the name it has now is one option. That name is SLEEF (SIMD Library for Evaluating Elementary Functions). We might also wish to name it something more generic as part of the project, as is our general custom (e.g. compiler-rt, libc++, libomp, etc.). > > (Which is the exact opposite of parallel_libs which is a meta-bucket > of dumping "...

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

Tried a bunch of them there (x86-64, haswell, znver2) and they all defaulted to 4-wide - haswell additionally caused some extra loop unrolling but still with 8-wide pows. Cheers, -Neil. On Thu, Jul 16, 2020 at 2:39 PM Roman Lebedev <lebedev.ri at gmail.com> wrote: > Did you specify the target CPU the code should be optimized for? > For clang that is -march=native/znver2/... /

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

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 >

Hi All, The original intend of this thread is to "Expose user provided vector function for auto-vectorization.” I originally proposed to use OpenMP `declare variant` for the sake of using something that is defined by a standard. The RFC itself is not about fully implementing the `declare variant` directive. In fact, given the amount of complication it is bringing, I would like to move the