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

[C Bergström via llvm-dev]

I'm positive +1 for inclusion since it has users, some development and
overall fits with the compiler genre.

If there's a bikeshed discussion on changing the name or where it
lives, I'd hope that we start a new discussion for that so it can be
easier to filter as well as stating clearly the pros/cons of each
proposal. I'm really really bored of reading all the bikeshed
discussions lately and the opinions, sometimes without strong
technical backing for why people choose Green or Blue.


On Thu, Jul 28, 2016 at 11:10 AM, Hal Finkel <hfinkel at anl.gov> wrote:
> ----- Original Message -----
>> From: "C Bergström" <cbergstrom at pathscale.com>
>> To: "Chandler Carruth" <chandlerc at gmail.com>
>> Cc: "Hal Finkel" <hfinkel at anl.gov>, "llvm-dev" <llvm-dev at lists.llvm.org>, "Matt Masten" <matt.masten at intel.com>,
>> "Naoki Shibata" <shibatch.sf.net at gmail.com>
>> Sent: Wednesday, July 27, 2016 9:43:34 PM
>> Subject: Re: [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..
>
> I don't think that parallel_libs needs propping - at the moment it is so new that parallel_libs-dev has zero messages. I don't see a strong need for another new top-level project, with whatever administrative overhead that implies. I'm not against it either. If the community wants a new top-level project for this library, then I'm sure we can make one.
>
>> 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..
>
> While many of us respect Chandler's opinion, that's not actually the way the community works.
>
>>
>> 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..
>
> To be clear, I think the community should decide on the name. Using the name it has now is one option. That name is SLEEF (SIMD Library for Evaluating Elementary Functions). We might also wish to name it something more generic as part of the project, as is our general custom (e.g. compiler-rt, libc++, libomp, etc.).
>
>>
>> (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?
>
> Because the RFC was on this list, and as you might recall, we recently had a big discussion on this list about mailing lists, and about how cross-posting between different lists is a real pain for the list moderators. Thus, I didn't. If we target the library to the parallel_libs project, then future discussion will go there. In the mean time, I am assuming that the relevant parties are on this list.
>
>>
>> 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.
>
> I agree that it is complementary to what is already in compiler-rt. That is why I suggested it as the second option.
>
> Thanks again,
> Hal
>
>>
>>
>> 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
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory