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
----- 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
On Tue, Sep 27, 2016 at 6:29 PM, Hal Finkel <hfinkel at anl.gov> wrote:> ----- 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.I didn't realize this is a patch specifically for parallel-libs. I'd really hope you reconsider compiler-rt or even a top level project home for this. Not to be taken too seriously.. just thinking out loud below Sorry to digress, but... So far "parallel-libs" is just a front for SE. Six posts on the mailing list and not much sign of life. So much potential, but what's happened since the initial commit in ~June? -------------- In contrast this has a more broad reach and general day-to-day use. Coupling that with another project which is already a strong dependency seems like a logical fit, no? compiler-rt isn't particularly big and would anyone complain against it being included there? Anyway - this library doesn't handle parallelism, it's vectorization. (semantics). Also there's already a bunch of built-ins that the compiler leverages in compiler-rt a somewhat similar fashion? lib/builtins ------------ For naming conventions - In general it may make sense to set a precedent early on what internally named functions should be. Off the cuff I'd propose __clg or something short and simple.. Consistency is typically a good thing, but anything with __ by the standard should be safe.. Sorry I can't help with the tests or benchmark side, but hopefully when things are ironed out a bit more I'll try to test as best as I can. Thanks
----- 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