similar to: [LLVMdev] SIMD trigonometry/logarithms?

The lack of an open-source vector math library (which is what you suggest here) prompted me to start a project "vecmathlib", available at < https://bitbucket.org/eschnett/vecmathlib>. This library provides almost all math functions available in libm, implemented in a vectorised manner, i.e. suitable for SSE2/AVX/MIC/PTX etc. In its current state the library has rough edges, e.g.

Portable Computing Language (pocl) v0.8 released Pocl's goal is to become an efficient open source (MIT-licensed) implementation of the OpenCL 1.2 (and soon OpenCL 2.0) standard. In addition to producing an easily portable open-source OpenCL implementation, another major goal of this project is improving performance portability of OpenCL programs with compiler optimizations, reducing the

----- Original Message ----- > From: "Dimitri Tcaciuc" <dtcaciuc at gmail.com> > To: llvmdev at cs.uiuc.edu > Sent: Sunday, January 27, 2013 3:42:42 AM > Subject: [LLVMdev] SIMD trigonometry/logarithms? > > > > Hi everyone, > > > I was looking at loop vectorizer code and wondered if there was any > current or planned effort to introduce SIMD

Hi Justin, I think having .bc math libraries for different backends makes perfect sense! For example, in case of NVPTX backend we have the following problem: many math functions that are only available as CUDA C++ headers could not be easily used in, for instance, GPU program written in Fortran. On our end we are currently doing exactly what you proposed: generating math.bc module and then link

Hi all. In fact, this is how we have implemented it in our compiler (intel's OpenCL). We have created a .bc file for every architecture. Each file contains all the SIMD versions for the functions to be vectorized. To cope with the massive amount of code to be produced, we implemented a dedicated tblgen BE for that purpose. We are willing to share that code with the llvm community, in case this

----- Original Message ----- > From: "Elior Malul" <elior.malul at intel.com> > To: "Michael Gottesman" <mgottesman at apple.com>, "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Thursday, February 14, 2013 8:33:42 AM > Subject: RE: [LLVMdev] SIMD

First let me say that I really like the notion of being able to plug in .bc libraries into the compiler and I think that there are many potential uses (i.e. vector saturation operations and the like). But even so it is important to realize the limitations of this approach. Generally implementations of transcendental functions require platform specific optimizations to get the best performance and

I'm wondering if it makes sense to instead supply a bc math library. I would think it would be easier to maintain and debug, and should still give you all of the benefits. You could just link with it early in the optimization pipeline to ensure inlining. This may also make it easier to maintain SIMD functions for multiple backends. On Sun, Jan 27, 2013 at 8:49 AM, Hal Finkel <hfinkel

----- Original Message ----- > From: "Dmitry Mikushin" <dmitry at kernelgen.org> > To: "Justin Holewinski" <justin.holewinski at gmail.com> > Cc: "Hal Finkel" <hfinkel at anl.gov>, "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Sunday, January 27, 2013 10:19:42 AM > Subject: Re: [LLVMdev] SIMD

On Fri, Jun 21, 2013 at 5:11 PM, Erik Schnetter <schnetter at cct.lsu.edu>wrote: > On Fri, Jun 21, 2013 at 7:54 AM, David Tweed <david.tweed at arm.com> wrote: > >> | LLVM does not currently have special lowering handling for round(), and >> I'll propose a patch to add that, but the larger question is this: should >> fast-math change the tie-breaking

----- Original Message ----- > > On Fri, Jun 21, 2013 at 5:11 PM, Erik Schnetter < > schnetter at cct.lsu.edu > wrote: > > > > > > > On Fri, Jun 21, 2013 at 7:54 AM, David Tweed < david.tweed at arm.com > > wrote: > > > > > > > | LLVM does not currently have special lowering handling for round(), > | and >

On Fri, Jun 21, 2013 at 7:54 AM, David Tweed <david.tweed at arm.com> wrote: > | LLVM does not currently have special lowering handling for round(), and > I'll propose a patch to add that, but the larger question is this: should > fast-math change the tie-breaking behavior of > | rint/nearbyint/round, etc. and, if so, should we make a specific effort > to > have all

On 2013-08-07, at 18:55 , Matt Arsenault <Matthew.Arsenault at amd.com> wrote: > On 08/07/2013 03:52 PM, Michele Scandale wrote: >> >> In the opencl specification is said that the four address spaces are disjoint, so my conclusion of non aliasing with the others. > In OpenCL 2.0, you can cast between the generic address space and global/local/private, so there's also

I am tracking down an x86-64 code generation problem that has to do with AVX instructions. The symptom is: a function is called, and the upper half of the function argument (which is short16) is zero. This happens only when I compile code with pocl, but not when I use clang and/or llc manually. I tracked this down to the following. The call site looks like vmovdqa 24064(%rsp), %ymm0 vmovdqa

Hi everyone, I was looking at loop vectorizer code and wondered if there was any current or planned effort to introduce SIMD implementations of sin/cos/exp/log intrinsics (in particular for x86-64 backend)? Cheers, Dimitri. -------------- next part -------------- An HTML attachment was scrubbed... URL:

FWIW, llvmpipe has C-binding code that generates (inlines) log/exp/pow/sin/cos functions of the fly, for an arbitrary number of elements (in most cases), and uses sse/avx intrinsics as available: http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/auxiliary/gallivm/lp_bld_arit.c The precision is 20bits, which is enough for 3D. But it wouldn't be difficult to have more (or even variable)

On 28/01/2013 12:49 AM, Hal Finkel wrote: > Ralf Karrenberg had implemented some of these as part of his > whole-function vectorization project: > https://github.com/karrenberg/wfv/blob/master/src/utils/nativeSSEMathFunctions.hpp > https://github.com/karrenberg/wfv/blob/master/src/utils/nativeAVXMathFunctions.hpp > Opinions on pulling these into the X86 backend? -Hal I've

https://bugzilla.samba.org/show_bug.cgi?id=5418 Summary: rsync error: error allocating core memory buffers (code 22) Product: rsync Version: 3.0.2 Platform: Other OS/Version: AIX Status: NEW Severity: major Priority: P3 Component: core AssignedTo: wayned@samba.org

Hi Justin, gentlemen, I'm afraid I have to escalate this issue at this point. Since it was discussed for the first time last summer, it was sufficient for us for a while to have lowering of math calls into intrinsics disabled at DragonEgg level, and link them against CUDA math functions at LLVM IR level. Now I can say: this is not sufficient any longer, and we need NVPTX backend to deal with

On 08/07/2013 03:52 PM, Michele Scandale wrote: > > In the opencl specification is said that the four address spaces are > disjoint, so my conclusion of non aliasing with the others. In OpenCL 2.0, you can cast between the generic address space and global/local/private, so there's also that to consider.