[Openmp-dev] Possibility of combining __kmpc_omp_task_with_deps and __kmpc_omp_task_begin/complete_if0

[Johannes Doerfert via Openmp-dev]

I generally agree, if mergeable is present we can version the
code otherwise we should not. All `if` conditions (and similar
things) should go into the runtime and be resolved there. Less
user code has various benefits and if we go into the runtime
anyway there is often little reason to not do everything there.

That said, here is my earlier attempt to simplify the task API:
   https://reviews.llvm.org/D71989

It is a prototype and someone needs to pick it up as I don't have
the bandwidth right now. While the API and __kmpc_task impl. are
not 100%, I would suggest we extend the API with placeholders and
move to integrate this. Then we fix up the corner cases as needed.

Bran, Giorgis, maybe either of you wants to add placeholder arguments
and proceed with this? We can mark is at experimental until we are
confident that the API is ready to be used.

~ Johannes


On 8/20/21 3:02 AM, Joachim Protze via Openmp-dev wrote:
> Hi Bran,
>
> the runtime performance for task if(0) would be way less important, if
> we get better codegen for mergeable tasks. I think this code
>
> #pragma omp task if(cond) mergeable
> {BLOCK}
>
> could translate to something like:
>
> if(cond)
> #pragma omp task
> {BLOCK}
> else
> {BLOCK}
>
>
>  From my perspective, programmers expect performance gain from just using
> task if(0) that simply cannot be met. Nevertheless the runtime tries to
> optimize the cost for this code path.
> A combination of if(0) and mergeable could really provide the expected
> performance gain, because it completely avoids the task creation cost.
> Furthermore, merging the task will allow for more optimization.
>
> Best
> Joachim
>
>
> Am 20.08.21 um 01:20 schrieb Bran Hagger via Openmp-dev:
>> Hello,
>>
>> I noticed that Giorgis Georgakoudis had done some work to simplify the
>> code gen for #pragma omp parallel and #pragma omp parallel if()
>> with https://reviews.llvm.org/D95976
>> <https://reviews.llvm.org/D95976> so that both cases generate a call to
>> __kmpc_parallel_51 and the if condition is handled in the runtime.
>>
>> Like #pragma omp parallel, #pragma omp task supports an if clause and
>> the runtime calls generated for #pragma omp task if(false) are very
>> different than the runtime calls generated for a task without an if
>> condition or in the case where the condition evaluates to true.
>>
>> Are there any plans or interest in simplifying the code generation for
>> #pragma omp task as well?
>>
>> There are definitely reasons why keeping the code generation as it is
>> right now might be preferable. There is certain optimization information
>> (such as interference, for example) which can be applied only when the
>> task is not deferred - that is, in the #pragma omp task if(false) case -
>> but the same is true for the #pragma omp parallel if(false) case.
>>
>> Best,
>> Bran Hagger (he/him)
>>
>> _______________________________________________
>> Openmp-dev mailing list
>> Openmp-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev
>>
> _______________________________________________
> Openmp-dev mailing list
> Openmp-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev