[PATCH] D32826: Move Parallel.h from LLD to LLVM

Zachary Turner via llvm-commits llvm-commits at lists.llvm.org
Thu May 4 14:53:46 PDT 2017


I interpreted the comment about using ThreadPool as replacing the homegrown
task pool in Parallel.h, which is not used on the ConcRT path.  I agree
that we cannot lose the ConcRT codepath.

That said, I'm still not sure if I'm the right person to switch to make the
switch over to ThreadPool.  I mean, I can try, but yea..  I'm not crazy
about touching something this low-level that relates to multi-threaded code.

On Thu, May 4, 2017 at 2:45 PM Michael Spencer <bigcheesegs at gmail.com>
wrote:

> On Thu, May 4, 2017 at 11:41 AM, Rui Ueyama via Phabricator <
> reviews at reviews.llvm.org> wrote:
>
>> ruiu added a comment.
>>
>> If we are going to examine this file, I strongly recommend porting the
>> same functionalities (i.e. parallel_for and parallel_for_each) on top of
>> llvm/Support/ThreadPool.h. I don't think that is hard to do as TheadPool.h
>> seems to provide the same functionality as this file. That would be easier
>> than review this file again.
>>
>>
>> https://reviews.llvm.org/D32826
>>
>>
>>
>>
> My issue with just using Support/ThreadPool for everything is that
> lld/Parallel.h uses ConcRT on Windows and is quite a bit faster than both
> our implementations of thread pools. I don't want to punish Windows
> performance. I'd also rather have our interface match whatever the standard
> is doing in terms of parallel task execution.
>
> - Michael Spencer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170504/3a0ec088/attachment.html>


More information about the llvm-commits mailing list