[flang-commits] [mlir] [flang] WIP : [Flang][MLIR][OpenMP] Delayed privatisation of index variables (PR #75836)
Sergio Afonso via flang-commits
flang-commits at lists.llvm.org
Thu Jan 4 05:08:24 PST 2024
skatrak wrote:
I think this approach makes sense. If I understand it correctly, this would add an explicit dialect representation for the private clause of the OpenMP for/do loop and use it internally to privatize the loop index, which allows us only materializing the copy later during MLIR to LLVM IR translation. In that case, I think the best option is to create the alloca inside of the outlined function for the parallel region and then add lifetime markers similarly to what I proposed in #74843, but more simply since we would already have access to the relevant allocas there, and there would be no need of analyzing the MLIR loop body.
Ideally, if we were to outline the loop body into its own function, the best would be to create the alloca there and not have to deal with lifetime markers. But the process we have for this relies on using the code extractor on a loop that has already been created inside of the outlined function for the parallel section, so we either mark the allocation's lifetime so it can be sunk into the new outlined function or we generate it inside of the loop. I think the second case would result in a very slow execution or possibly even memory leaks when this second outlining is not done, so the first one seems like the safer option. Let me know if you'd like to explore that approach and I can update my patch / create another one to build on top of this.
I guess the idea would be to add the private, firstprivate and lastprivate args to all applicable OpenMP MLIR ops, and potentially modify the `DataSharingProcessor` to make it update these mappings as well?
https://github.com/llvm/llvm-project/pull/75836
More information about the flang-commits
mailing list