llvm dev - Jun 2016 - [cfe-dev] [Openmp-dev] RFC: Proposing an LLVM subproject for parallelism runtime and support libraries

> Again, this is a decision the LLVM community needs to make based on its own
cost/benefit analysis. We often don't start new projects with mature code --
in fact, doing that is an unusual case.
I can't speak for every new project, but the ones I've followed
closely (OMP hell) I can say that not a single piece of code was
accepted without a fight and that it was meant to be production grade
on every commit. It lived and lives partially outside the llvm tree
still as a result of this.. This is a great thing in many regards, but
now it's a double edged sword.

I have said this before and I'll say it again.. I wish the llvm
project would take a long hard look at how the Apache foundation
handles projects. They have an incubator process which clearly defines
the whole applications to acceptance process. Nothing like that exists
around here and the result we get is long email threads where it's all
just opinions without any tangible reference or SOP.

I'm not sure the Apache foundation has a height requirement but most
of the projects applying to join have at least some traction and are
usually small communities trying to join a bigger one.. Not next to
nothing and just trying to bootstrap..

(Mostly trying to re-focus the thread somewhat)

Given support from Mehdi, Renato, and especially Hal who has contributed
specifically in this area to LLVM as a whole, and no strong objections from
significant contributors (I feel like the primary concerns Intel raised
have been addressed, and we can keep working to make sure the libomptarget
stuff is integrated effectively), I think we should move forward.

I understand that you still disagree with Hal and Mehdi here Chris, but I
don't think debating more in this thread is going to resolve anything.
While I'm still very interested in your feedback here and on the actual
implementation of SE, I think we should go with the direction suggested by
more significant contributors to the project. I'm inclined to trust the
judgement of Hal, Renato, and Mehdi in the absence of objections from other
significant contributors.

So Jason, I would suggest starting a fresh thread with Tanya to get the
mechanical stuff in place for the new project. We can discuss whether to
have a separate mailing list, etc. there. And then can start posting
patches based on the charter and other stuff you've already worked up.

(Also happy for folks who've been keeping silent to chime in with more
opinions! Just assuming that most don't have strong feelings either way at
this point.)

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160602/ca4773bc/attachment.html>

On Thu, Jun 2, 2016 at 11:47 AM, Chandler Carruth <chandlerc at
google.com> wrote:
> (Mostly trying to re-focus the thread somewhat)
>
> Given support from Mehdi, Renato, and especially Hal who has contributed
> specifically in this area to LLVM as a whole, and no strong objections from
> significant contributors (I feel like the primary concerns Intel raised
have
> been addressed, and we can keep working to make sure the libomptarget stuff
> is integrated effectively), I think we should move forward.
>
> I understand that you still disagree with Hal and Mehdi here Chris, but I
> don't think debating more in this thread is going to resolve anything.
While
> I'm still very interested in your feedback here and on the actual
> implementation of SE, I think we should go with the direction suggested by
> more significant contributors to the project. I'm inclined to trust the
> judgement of Hal, Renato, and Mehdi in the absence of objections from other
> significant contributors.
>
> So Jason, I would suggest starting a fresh thread with Tanya to get the
> mechanical stuff in place for the new project. We can discuss whether to
> have a separate mailing list, etc. there. And then can start posting
patches
> based on the charter and other stuff you've already worked up.
>
> (Also happy for folks who've been keeping silent to chime in with more
> opinions! Just assuming that most don't have strong feelings either way
at
> this point.)
yay for steamroller approach without actually addressing any of my
valid concerns. I'd expect nothing less from you Chandler, nice job..

It's not like they will be contributing code to this area and or have
contributed much to the areas of offloading. (Sorry Hal, but I may be
mistaken in your case.. I'd need to check commit logs)

The reasons Hal and others "support" your proposal is based on
"interest" or speculation at best. They haven't committed to
contribute code and their expertise in the areas of offloading is
probably narrow band. (Again sorry Hal, I know you work inside the OMP
community)

I expect if we had to take a vote it would be myself (who has
contributed to OMP btw, most of the ARM port, cmake stuff and lots of
code reviews) and Intel - (who has significantly contributed to OMP).
Just because I don't submit patches to the pass manager doesn't mean I
have zero contribution. I'm annoyed you don't even have your facts
straight.

My vote isn't -1, but it is lets revisit this when the project is more
mature. Are you totally blind to the fact that we DO NOT NEED ANOTHER
PROGRAMMING MODEL. There should be super strong and compelling reasons
to do that, which you have not demonstrated.

New programming model == super big hammer. It's like saying everything
else is so broken beyond repair we need to invent something wholly
new.

Intel can you please weigh in


Thanks