From: "C Bergström" <firstname.lastname@example.org>
To: "Chandler Carruth" <email@example.com>
Cc: "Hal Finkel" <firstname.lastname@example.org>, "llvm-dev" <email@example.com>, "Matt Masten" <firstname.lastname@example.org>,
"Naoki Shibata" <email@example.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
I agree that it is complementary to what is already in compiler-rt. That is why I suggested it as the second option.