[llvm-dev] RFC: SIMD math-function library

Wed Sep 28 19:19:57 PDT 2016

----- Original Message -----
> From: "Hal Finkel via llvm-dev" <llvm-dev at lists.llvm.org>
> To: "C Bergström" <cbergstrom at pathscale.com>
> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Naoki Shibata" <shibatch.sf.net at gmail.com>, "Matt Masten"
> <matt.masten at intel.com>
> Sent: Tuesday, September 27, 2016 5:29:23 AM
> Subject: Re: [llvm-dev] RFC: SIMD math-function library
> 
> ----- Original Message -----
> > From: "C Bergström" <cbergstrom at pathscale.com>
> > To: "Hal Finkel" <hfinkel at anl.gov>
> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Matt Masten"
> > <matt.masten at intel.com>, "Naoki Shibata"
> > <shibatch.sf.net at gmail.com>
> > Sent: Monday, September 26, 2016 10:49:57 PM
> > Subject: Re: [llvm-dev] RFC: SIMD math-function library
> > 
> > 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?
> 
> compiler-rt is a conglomeration of many different things, and it is
> not clear to me that this needs to be yet-another thing that lives
> there. parallel-libs thematically makes sense to me; I really don't
> have a strong opinion about this. One thing that making the patch
> for parallel-libs made me realize was how much cmake functionality
> is currently housed in compiler-rt that perhaps should be made
> reusable somehow by all of the library projects.
> 
> > 
> > 1) Why rename C files to C++ (consistency?)
> 
> Consistency (and the code might naturally use several C++ features,
> such as function overloading and templates, as we refactor it).
> 
> > 
> > 2) It seems your "x" prefix is probably safe, but more safe may be
> > clg
> > (like clgsinf) - This is a bit verbose of course, but I think
> > you're
> > trying to avoid a collision, right? If this library is meant only
> > for
> > internal compiler usage and not exposed, wouldn't __vsinf be really
> > what makes sense? (If Apple or others use this it shouldn't be
> > public
> > facing) If there is meant to be a user facing API - maybe it could
> > be
> > exposed as an alias with a conflicting API, but not automatically
> > used
> > in the compiler.. This would mean there's both __vsinf (or xsinf if
> > you prefer) as well as sinf..
> 
> All of the external functions are prefixed with __x, which should be
> pretty safe. The x was in the library before, I just added the __.
> If you have a naming scheme you'd prefer, please feel free to
> suggest one (or more than one).
> 
> > 
> > 3) I see #if for SP and DP, but what about REAL10 and REAL16? Any
> > plans?
> 
> I have no immediate plans; I also don't know of any targets that will
> support vectors of these higher-precision types.
> 
> > 
> > 4) It appears to be a known situation, but I'm a little
> > uncomfortable
> > in general with having a top level project without *any* way to
> > test
> > and validate it. The cmake option is there, but does it do what I
> > assume it should do? If it does could you add a README with a small
> > amount of information on how to setup the tests.. (I'm also
> > strongly
> > against mpfr)
> 
> In my opinion, this can't be committed at all without tests; having
> the regression tests is a must. We need to decide how to do them.

I've ported the unit tests to the gtest framework that LLVM uses and updated the patch. The library should now be pretty-well tested.

 -Hal

> 
> > 
> > 5) Is there any benchmarks we can test this with to see the
> > benefit?
> 
> Good question. Eric F. has been working on adding benchmarks to
> libcxx, and we should consider leveraging that somehow to make sure
> we have benchmarks for this too.
> 
> > 
> > 6) Lastly, if Apple or Linux introduce something similar, what's
> > the
> > benefit of having this vs that? How do we decide which one to use
> > or
> > should the compiler just support both concurrently?
> > 
> 
> This isn't really an if. glibc now has libmvec, which provides a
> subset of the functionality proposed here for single and double
> precision (at least for x86). Apple's Accelerate framework vecLib
> provides much of this functionality, but only for single precision.
> What's provided here is fairly comprehensive, for both single and
> double precision, plus is easy to port to other architectures.
> 
> Thanks again,
> Hal
> 
> > 
> > On Tue, Sep 27, 2016 at 9:34 AM, Hal Finkel via llvm-dev
> > <llvm-dev at lists.llvm.org> wrote:
> > > Hi again,
> > >
> > > To start the conversation (and review) of the technical elements,
> > > I've put together an initial patch:
> > > https://reviews.llvm.org/D24951
> > >
> > > Thanks again,
> > > Hal
> > >
> > > ----- Original Message -----
> > >> From: "Hal Finkel via llvm-dev" <llvm-dev at lists.llvm.org>
> > >> To: "Chandler Carruth" <chandlerc at gmail.com>,
> > >> llvm-dev at lists.llvm.org
> > >> Cc: "Naoki Shibata" <shibatch.sf.net at gmail.com>, "Matt Masten"
> > >> <matt.masten at intel.com>
> > >> Sent: Wednesday, July 27, 2016 10:46:22 AM
> > >> Subject: Re: [llvm-dev] 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 together already, and in
> > >> part because vectorization is a form of parallel execution.
> > >> Thoughts?
> > >>
> > >> Thanks again,
> > >> Hal
> > >>
> > >> ----- Original Message -----
> > >> > From: "Xinmin Tian" <xinmin.tian at intel.com>
> > >> > To: "Naoki Shibata" <shibatch.sf.net at gmail.com>, "Hal Finkel"
> > >> > <hfinkel at anl.gov>
> > >> > Cc: llvm-dev at lists.llvm.org, "Chandler Carruth"
> > >> > <chandlerc at gmail.com>, "Matt Masten" <matt.masten at intel.com>
> > >> > Sent: Thursday, July 14, 2016 11:55:24 PM
> > >> > Subject: RE: RFC: SIMD math-function library
> > >> >
> > >> > 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 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 Shibata [mailto:shibatch.sf.net at gmail.com]
> > >> > Sent: Thursday, July 14, 2016 9:38 PM
> > >> > To: Hal Finkel <hfinkel at anl.gov>
> > >> > Cc: llvm-dev at lists.llvm.org; Chandler Carruth
> > >> > <chandlerc at gmail.com>;
> > >> > Tian, Xinmin <xinmin.tian at intel.com>; Masten, Matt
> > >> > <matt.masten at intel.com>
> > >> > Subject: Re: RFC: SIMD math-function library
> > >> >
> > >> >
> > >> > 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 Shibata
> > >> >
> > >> >
> > >> > On 2016/07/15 12:53, Hal Finkel wrote:
> > >> > > Hi again,
> > >> > >
> > >> > > As this RFC implies, I've been using the SLEEF library
> > >> > > proposed
> > >> > > here with Clang/LLVM for many years, and fully support its
> > >> > > adoption into the LLVM project.
> > >> > >
> > >> > > I'm CC'ing Matt and Xinmin from Intel who have started
> > >> > > working
> > >> > > on
> > >> > > contributing support for their SVML library to LLVM
> > >> > > (http://reviews.llvm.org/D19544), and I understand plan to
> > >> > > contribute (some subset of) the vector math functions
> > >> > > themselves.
> > >> > > I'm also excited about Intel's planned contributions.
> > >> > >
> > >> > > Here's how I currently see the situation: Regardless of what
> > >> > > Intel
> > >> > > contributes, we need a solution in this space for many
> > >> > > different
> > >> > > architectures. From personal experience, SLEEF is relatively
> > >> > > easy
> > >> > > to port to different architectures (i.e. different vector
> > >> > > ISAs),
> > >> > > and has already been ported to several. The performance is
> > >> > > good
> > >> > > as
> > >> > > is the accuracy. I think it would make a great foundation
> > >> > > for
> > >> > > a
> > >> > > vector-math-function runtime library for the LLVM project. I
> > >> > > don't
> > >> > > know what routines Intel is planning to contribute, or for
> > >> > > what
> > >> > > architectures they're tuned, but I expect we'll want to use
> > >> > > those
> > >> > > implementations on x86 platforms where appropriate.
> > >> > >
> > >> > > Matt, Xinmin, what do you think?
> > >> > >
> > >> > > Thanks again,
> > >> > > Hal
> > >> >
> > >> >
> > >>
> > >> --
> > >> Hal Finkel
> > >> Assistant Computational Scientist
> > >> Leadership Computing Facility
> > >> Argonne National Laboratory
> > >> _______________________________________________
> > >> LLVM Developers mailing list
> > >> llvm-dev at lists.llvm.org
> > >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> > >>
> > >
> > > --
> > > Hal Finkel
> > > Lead, Compiler Technology and Programming Languages
> > > Leadership Computing Facility
> > > Argonne National Laboratory
> > > _______________________________________________
> > > LLVM Developers mailing list
> > > llvm-dev at lists.llvm.org
> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> > 
> 
> --
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory