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

Tue Sep 27 03:29:23 PDT 2016

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

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