[Openmp-dev] Possibility of combining __kmpc_omp_task_with_deps and __kmpc_omp_task_begin/complete_if0
Georgakoudis, Giorgis via Openmp-dev
openmp-dev at lists.llvm.org
Mon Aug 23 06:05:24 PDT 2021
I also agree with the idea of simplifying Clang code generation in favor of letting the runtime handle the execution.
Given successes of the OpenMPOpt pass in analyzing and optimizing OpenMP, I consider LLVM to be the right place to put optimizations so other frontends can benefit.
All in all, I think it makes sense to simplify the task API. I'll need some time to go through Johannes's patch and follow with suggestions.
Bran, please include me in the discussion if you move faster than me.
On 8/20/21, 9:24 AM, "Johannes Doerfert" <johannesdoerfert at gmail.com> wrote:
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:
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.
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
> could translate to something like:
> #pragma omp task
> 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.
> Am 20.08.21 um 01:20 schrieb Bran Hagger via Openmp-dev:
>> 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://urldefense.us/v3/__https://reviews.llvm.org/D95976__;!!G2kpM7uM-TzIFchu!kO-NhKTp7G1Q_jLNhSFVi9X6gq3vfJtLyYcFWZ3bzHVsTVEHqkzJi0FG0850k6-NM1mAuA$
>> <https://urldefense.us/v3/__https://reviews.llvm.org/D95976__;!!G2kpM7uM-TzIFchu!kO-NhKTp7G1Q_jLNhSFVi9X6gq3vfJtLyYcFWZ3bzHVsTVEHqkzJi0FG0850k6-NM1mAuA$ > 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.
>> Bran Hagger (he/him)
>> Openmp-dev mailing list
>> Openmp-dev at lists.llvm.org
> Openmp-dev mailing list
> Openmp-dev at lists.llvm.org
More information about the Openmp-dev