Third-party libraries policy

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. Are third-party libraries welcomed to be added in LLVM? If yes, what folder structure should we arrange?

B.R.

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?

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

Mehdi Amini <mehdi.amini@apple.com> 於 2016年10月19日 上午11:30 寫道:

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.
I think neither standard library nor LLVM support library provide this functionality.

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 Amini <mehdi.amini@apple.com> 於 2016年10月19日 上午11:30 寫道:

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 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…)

Mehdi Amini <mehdi.amini@apple.com> 於 2016年10月19日 上午11:47 寫道:

Mehdi Amini <mehdi.amini@apple.com> 於 2016年10月19日 上午11:30 寫道:

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

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.