[llvm-dev] RFC: SIMD math-function library
C Bergström via llvm-dev
llvm-dev at lists.llvm.org
Tue Sep 27 04:10:12 PDT 2016
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
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?
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
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
More information about the llvm-dev