thr3ads.net - llvm dev - [llvm-dev] RFC: SIMD math-function library [Sep 2016]

If this information is useful, please help other people find it:
Share via:

Hal Finkel via llvm-dev

2016-Jul-27 15:46 UTC

[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

Tian, Xinmin via llvm-dev

2016-Jul-27 16:42 UTC

head link

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

I don't have a strong preference using either parallel_lib or compiler-rt as
the home for vectorlib, or a new one. Assume we go with parallel_libs, the
structure is more or less like below, right?

                   parallel_libs
                            |
  -------------------------------------------------------------
  |                                                 |                          |
vector                             streamexecutor     offload
  |
--------------------
 |         |           |
x86   arm   power 

Thanks,
Xinmin

-----Original Message-----
From: Hal Finkel [mailto:hfinkel at anl.gov] 
Sent: Wednesday, July 27, 2016 8:46 AM
To: Chandler Carruth <chandlerc at gmail.com>; llvm-dev at lists.llvm.org
Cc: Masten, Matt <matt.masten at intel.com>; Naoki Shibata
<shibatch.sf.net at gmail.com>; Tian, Xinmin <xinmin.tian at
intel.com>
Subject: Re: 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

Chandler Carruth via llvm-dev

2016-Jul-28 02:29 UTC

head link

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

On Wed, Jul 27, 2016 at 8:46 AM Hal Finkel via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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?
>
I share your preference and the basis for it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160728/f5d7b637/attachment.html>

C Bergström via llvm-dev

2016-Jul-28 02:43 UTC

head link

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

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 by points like: maintaining a clear
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..

(Which is the exact opposite of parallel_libs which is a meta-bucket
of dumping "stuff") Another reason why parallel_libs doesn't make
sense is that it's still extremely low visibility or relevance. Was a
mailing list setup for it? If it's a real project, why wasn't that
list on cc?

I'd opt to go with what the author wants or worst case compiler-rt in
the event people refuse to create another repo. The nature of the
functions it implements is complementary to what's there already,
better visibility as well as something people may be checking out
already.

On Thu, Jul 28, 2016 at 10:29 AM, Chandler Carruth via llvm-dev
<llvm-dev at lists.llvm.org> wrote:> On Wed, Jul 27, 2016 at 8:46 AM Hal Finkel via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>>
>> 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?
>
>
> I share your preference and the basis for it.
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

Hal Finkel via llvm-dev

2016-Sep-27 01:34 UTC

head link

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

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

C Bergström via llvm-dev

2016-Sep-27 03:49 UTC

head link

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

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

Seemingly Similar Threads

Search for more possibly parallel threads

llvm dev - Sep 2016 - RFC: SIMD math-function library

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

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

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

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

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

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

Seemingly Similar Threads