[llvm-dev] Third-party libraries policy

[Daniel Berlin via llvm-dev]

Uh, if oyu really have any plans to ever try to upstream it, talking about
third party library usage is the least of your problems.
If you ever plan on trying to upstream something as important as
"parallelizing code generation", you should propose, design, build, etc, it
upstream.
Not try to do it and then try to upstream it.

Something like that requires a very large amount of design consensus.


On Tue, Oct 18, 2016 at 8:57 PM, Bekket McClane via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
> Mehdi Amini <mehdi.amini at apple.com> 於 2016年10月19日 上午11:47 寫道：
>
>
> On Oct 18, 2016, at 8:41 PM, Bekket McClane <bekket.mcclane at gmail.com>
> wrote:
>
>
> Mehdi Amini <mehdi.amini at apple.com> 於 2016年10月19日 上午11:30 寫道：
>
>
> On Oct 18, 2016, at 6:28 PM, Bekket McClane via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Hi,
> The LLVM variant we're building now contains usage of a third-party
> threading library, and we would like to push our work upstream in the
> future.
>
>
> What is the motivation?
> For instance what is this doing that std::thread or llvm::ThreadPool is
> not providing? Why is it useful to have it in tree?
>
>
> The library we’re using is actually a routine library which provides
> extremely fast context switching similar to Go routine.
>
>
> That’s interesting, but are you intending to use this as a runtime to go
> with the code *generated by LLVM* or are you planning to use this to
> implement the compiler internals?
>
> This is a significant difference, as in the first case we have started a
> “parallel libs” subproject here: http://llvm.org/svn/
> llvm-project/parallel-libs/trunk/
> I’m not sure we would take an external lib, but we would consider
> integrating as a new LLVM subproject if there was a motivation on both side
> to get there.
>
> For the second case (using it in the compiler itself), what kind of uses
> do you have for this in your “LLVM variant”?
>
>
> I think we’re the second case, since we are going to parallelize "compiler
> itself”. In short, we’re planning to parallelize the code generation
> process in aid of JIT compilation.
>
>
> I think neither standard library nor LLVM support library provide this
> functionality.
>
>
> We’re implementing C++ coroutine though: https://www.youtube.
> com/watch?v=8C8NnE1Dg4A
> (Not sure how it relates to what you’re doing, but since you mentioned
> coroutines…)
>
>
> Yes, I think that resembles to what we want. Thanks for providing.
>
> B.R.
> McClane
>
>
> —
> Mehdi
>
>
>
>
>
>
> Are third-party libraries welcomed to be added in LLVM? If yes, what
> folder structure should we arrange?
>
>
> In general we avoid them as much as possible and need a really compelling
> justification to include one.
> Chris reinstated this position recently: http://lists.llvm.
> org/pipermail/llvm-dev/2016-September/105166.html
>
>
> Thanks, we would take this policy into our consideration.
>
> B.R.
> McClane
>
>
> —
> Mehdi
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161018/ffa60e5f/attachment.html>