[llvm-dev] PSA: Parallel STL algorithms available in LLVM

[Zachary Turner via llvm-dev]

It seems to me like this would be the responsibility of the executor being
used.  You might have one parallel executor which uses a fixed size thread
pool, and another which can dynamically add more threads if they are
needed.  In any case, I would still hope that it be specified by the time
of standardization.  Since the current executor stuff is all magically
hidden away and inaccessible, I guess it wouldn't hurt to add this logic
there?

On Wed, May 10, 2017 at 8:36 PM Zachary Turner <zturner at google.com> wrote:

> It's hard to say.  By definition it appears undefined (in the sense that
> the TS literally does not define it), but on the other hand it is a TS and
> this issue would (hopefully) come up and be specified before it made it to
> standardization.
>
> Supporting recursive parallel calls certainly seems like desirable
> behavior, so from my point of view it would be nice to make sure it works.
> Not sure if others feel differently.
>
> On Wed, May 10, 2017 at 8:08 PM Scott Smith <scott.smith at purestorage.com>
> wrote:
>
>> The spec doesn't seem to say anything about recursive calls to parallel
>> functions.  In my mind that means the functions must support it, since it
>> doesn't explicitly say it does not need to support it.  Do you think that's
>> accurate?
>>
>> If so, I'll rely on that behavior in LLDB, and extend the implementation
>> in LLVM accordingly.
>>
>> On Wed, May 10, 2017 at 5:37 PM, Zachary Turner via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> Hi all,
>>>
>>> This is just a PSA that as of r302752, 3 parallel algorithms (for_each,
>>> for_each_n, and sort) are available in llvm/Support/Parallel.h.
>>>
>>> Effort was made to match the C++ Parallelism TS N4507 [
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4507.pdf] as
>>> closely as possible, but some aspects were intentionally omitted.
>>>
>>> No support is added for the executor proposal N4406 [
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4406.pdf], but
>>> I plan to try to work on this in the future, with no specified timeline.
>>>
>>>
>>>
>>> _______________________________________________
>>> 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/20170511/d1af0798/attachment.html>