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

Mon Sep 26 20:49:57 PDT 2016

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

3) I see #if for SP and DP, but what about REAL10 and REAL16? Any plans?

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)

5) Is there any benchmarks we can test this with to see the benefit?

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?

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