[Openmp-commits] [PATCH] D77609: [OpenMP] Added the support for unshackled task in RTL

[Johannes Doerfert via Phabricator via Openmp-commits]

jdoerfert added a comment.

In D77609#2075986 <https://reviews.llvm.org/D77609#2075986>, @protze.joachim wrote:

> In D77609#1967875 <https://reviews.llvm.org/D77609#1967875>, @tianshilei1992 wrote:
>
> > > What tasks should/can be given to unshackled threads? Is it user's decision, or runtime decision, or some combination (suggest new clause/hint?)?
> >
> > That is a good point. For current purpose, it can only be used by compiler. If a `nowait` target is not in any parallel region, an unshackled task will be created by compiler. The motivation is, just for your information in case that you don't know the context, the "unshackled" here means it will not be bound to any parallel region. That is particularly useful for the case I mentioned. Of course it also implies, especially in current implementation design, they're actually implicitly bound to the same outer-most parallel region. Regular task synchronization should NOT work for them, except one special case that the `taskwait` depends on an unshackled task. What's more, since it is not part of spec, it can not be used by users. Of course if it is part of spec in the future, users can decide it and there must be new clause for it.
>
>
> According to the OpenMP specification, you always have an implicit parallel region surrounding the whole execution. Your target nowait binds to this implicit parallel region. For this reason, the target task must respect all means of synchronization like dependencies, taskwait, barrier, ...


Sure. Do you have any scenario in mind you expect not to work? The encountering thread will wait for these "unshackled" tasks on a taskwait for example. They also interact with `depend` clauses the way you want them too, as far as I can tell.

> What is the concrete scenario, in which you need this monitor thread to schedule device activity?

As an alternative to "real tasks":

- no explicit host parallel region
- all threads in the host parallel region busy

As an alternative to how detached tasks would look like (see below):

- no asynchronous native runtime calls available (e.g., host)
- can be much faster if host dependence resolution is involved
- is as fast as the async native runtime call solution in XL in the absence of dependences but *reusable* for other cases & runtimes

> Did you consider to use detached tasks to implement asynchronous target offloading?

Sure, but they don't work too different after all, at least not in the way you would use them here.
You would *not* create a task to be picked up, as that has the drawbacks mentioned above, among other things.
You would execute async native runtime calls and instruct the native runtime to fulfill the event once all work has been done.
>From the users perspective this is no different than a new thread picking it up (as the native runtime actually *is* a new thread picking it up).


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77609/new/

https://reviews.llvm.org/D77609