[Mlir-commits] [mlir] [OpenMP][MLIR] Add omp.distribute op to the OMP dialect (PR #67720)
Jan Leyonberg
llvmlistbot at llvm.org
Tue Oct 24 10:21:00 PDT 2023
jsjodin wrote:
> Since the distribute construct exists individually and applies to both `simd` and `do` constructs, could you summarize what you plan for each of the following? !$omp distribute !$omp distribute simd !$omp distribute parallel do !$omp distribute parallel do simd
>
> `omp.dwsloop` will work for `!$omp distribute` but how will this work for `!$omp distribute simd, !$omp distribute parallel do`. `omp.wsloop (type=DistributeFor)` will work for `!$omp distribute parallel do` and probably `!$omp distribute`, does it work fine for `!$omp distribute simd`, `!$omp distribute parallel do simd`?
Yes, this is indeed a problem. It is also a problem with loop transformations e.g.
````
#pragma omp target teams distribute parallel for
#pragma omp tile sizes(2,2)
for (int i = 0; i < N; ++i) {
for (int j = 0; j < M; ++j) {
code(i,j);
}
}
````
Where the tiling happens first and the distribute would apply to the outermost tiled loop out of the 4 loops that are the result of the tiling. I think a missing piece are side effects. I believe that marking omp.distribute, omp.parallel, omp.teams with [MemoryEffects<[MemWrite]>] is necessary to capture the dependencies between these operations and e.g. omp_get_num_threads(). By adding the side effects as I mentioned above, having a wrapper op would work, and since we cannot associate 'distribute' with an existing loop it will not be possible to have a omp.dwsloop. So I guess my previous backtrack would not work because of this and we're back to the wrapper option.
https://github.com/llvm/llvm-project/pull/67720
More information about the Mlir-commits
mailing list