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

[Jason Henline via llvm-dev]

Andrey,

I may have misunderstood Chandler, but I think it would be good to house
libomptarget together with SE in the new project. I suspect he means to
leave the option open for the libomptarget developers to choose the best
option as they see fit.

In terms of organization, I would expect the project initially to contain a
StreamExecutor directory and a libomptarget directory where each project
could work separately.

When it comes to the difference in review process between the two projects,
I don't know the answer. I would expect the new project to handle reviews
similar to the way they are handled in the LLVM project itself, so I don't
know if there would be any difference compared to what is happening now
with libomptarget.

On Wed, Apr 27, 2016 at 9:32 AM C Bergström <openmp-dev at lists.llvm.org>
wrote:

> I respect Hal's more tactful approach and response..
>
> Let me play devils advocate for a minute
>
> 1) Yet another programming model - Is the advantage spelled out
> somewhere? (I know there are reasons, but I'd like to see a FAQ or
> this clearly documented. Examples pretty please.. More for long term
> than my own selfish benefit)
> 2) Is this an "open standard" - If I wanted to propose a major change
> to SE - how would I or someone else go about it? OpenMP/ACC have more
> or less clearly defined paths for new features.. What's the governing
> policy here.. Bug fixes are easy to deal with, but does Google have
> final say on the roadmap..
> 3) When the project is created - will it include lots of good tests?
> 4) It's probably used internally @google - who else will be using
> this? Is the target HPC, Android.. etc
>
> Lastly - sorry, but I don't like this kick-the-can approach to what
> should be proper engineering and planning upfront. Can someone @google
> gentleman's promise to actively work on playing nice with other
> projects, specifically OpenMP and Intel. From my perspective nothing
> stops Google from tossing it up on github or google code and letting
> it stay there until all the pieces are in the correct place. Why it
> *must* be an llvm project now doesn't make sense to me. When the shoe
> was on the other foot (OpenMP) there was all sorts of shit and redtape
> Intel (and others) had to jump around to get it included. Google has a
> lot of good karma in the llvm community and maybe that's the
> difference..
> _______________________________________________
> Openmp-dev mailing list
> Openmp-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160427/3d18baf2/attachment.html>