This is an archive of the discontinued LLVM Phabricator instance.

[Flang][OpenMP] Refactor to properly fix privatisation of loop bounds
ClosedPublic

Authored by kiranchandramohan on May 25 2023, 2:26 PM.

Details

Summary

The OpenMP loop Operations have the bounds attached to them. If the
loop bounds are privatised then the privatisation has to happen
before the loop operation is created. To do this the privatisation
is split into two steps. The first step performs cloning and
firstprivate handling, the second step performs lastprivate handling.

This also reverts the changes in the temporary fix (D127137).

Fixes https://github.com/flang-compiler/f18-llvm-project/issues/1171#issuecomment-1143880545
Fixes https://github.com/flang-compiler/f18-llvm-project/issues/1171#issuecomment-1119997442

Fixes #60872

Diff Detail

Event Timeline

Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptMay 25 2023, 2:26 PM
kiranchandramohan requested review of this revision.May 25 2023, 2:26 PM
NimishMishra accepted this revision.Jun 5 2023, 12:56 AM

LGTM

flang/lib/Lower/OpenMP.cpp
102

Nit: "all privatisation clauses" instead of "al ..."

112

Not a hard comment but does it make more sense to name these steps? Rather than leaving them as "Step1" and "Step2" ? Like "Step2" can be "processLastPrivateClause" or something.

Again, this is purely from readability perspective. In any case, the comment here clearly distinguishes Step1 and Step2.

1555

Unintentional?

1571

This looks OK. Splitting privatization in steps 1 and 2 have cleanly allowed privatization of loop variables before creation of loop operations (step 1). Lastprivate is left for later (step 2) when we have the MLIR operation information.

flang/test/Lower/OpenMP/single.f90
75–77

This change is OK. private(x) firstprivate(y) should cuase the allocations within omp.single code block, which wasn't really happening before.

This revision is now accepted and ready to land.Jun 5 2023, 12:56 AM
kiranchandramohan marked 3 inline comments as done.Jun 5 2023, 9:04 AM

Thanks @NimishMishra for the review.

flang/lib/Lower/OpenMP.cpp
112

Thanks, that is a good point.
I will do this in further refactorings or cleanups. The plan is to come to the following steps. And at that point, we can do the renaming.
-> clone
-> copyfirstprivate
-> copylastprivate
-> finalize (for allocatables, or derived types with finalizers)

flang/test/Lower/OpenMP/single.f90
75–77

I had previously suggested hoisting them. But I felt this is better for simplicity. But going forward there is the following further work,

  1. Provide an option to hoist allocas to the nearest region that will be function-like.
  2. Insert llvm.stack-save and llvm.stack-restore so that if the single is inside a loop it does not cause runaway allocation.