> 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 <mailto: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. 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 <http://lists.llvm.org/pipermail/llvm-dev/2016-September/105166.html>Thanks, we would take this policy into our consideration. B.R. McClane> > — > Mehdi >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161019/9906f65b/attachment.html>
> On Oct 18, 2016, at 8:41 PM, Bekket McClane <bekket.mcclane at gmail.com> wrote: > > >> Mehdi Amini <mehdi.amini at apple.com <mailto: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 <mailto: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/ <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 <https://www.youtube.com/watch?v=8C8NnE1Dg4A> (Not sure how it relates to what you’re doing, but since you mentioned coroutines…) — 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 <http://lists.llvm.org/pipermail/llvm-dev/2016-September/105166.html> > Thanks, we would take this policy into our consideration. > > B.R. > McClane >> >> — >> Mehdi >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161018/bc006346/attachment.html>
> 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 <mailto:bekket.mcclane at gmail.com>> wrote: >> >> >>> Mehdi Amini <mehdi.amini at apple.com <mailto: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 <mailto: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/ <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 <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 <http://lists.llvm.org/pipermail/llvm-dev/2016-September/105166.html> >> Thanks, we would take this policy into our consideration. >> >> B.R. >> McClane >>> >>> — >>> Mehdi-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161019/a6739be5/attachment-0001.html>