[flang-commits] [flang] [flang][OpenMP] Support ALLOCATABLE list items in LINEAR (PR #228827)

[Aditya Trivedi via flang-commits]

adit4443ya wrote:


Thanks @tblah, agreed: this patch is only partial. The private copy is a stack slot behind a hand-built descriptor, so each thread doesn't get a real allocation or deallocation.

private already handles this properly for allocatables. The omp.private recipe does fir.allocmem/fir.freemem, and the translation inlines init/dealloc. I think linear should use the same mechanism. Right now linear has no recipe and no block args. The translation allocates a slot of linear_var_types and rewrites uses of the original pointer, which is exactly what breaks for a descriptor.

Proposal: let linear items optionally carry an omp.private recipe, the same way private items do:

```mlir
// Already generated today for private(a):
omp.private {type = private} @_QFsEa_private_box_heap_i32 : !fir.box<!fir.heap<i32>> init {
  // fir.allocmem if the original is allocated, else a null box
} dealloc {
  // fir.freemem
}

omp.simd linear(@_QFsEa_private_box_heap_i32 %a#0 -> %arg0 : !fir.ref<!fir.box<!fir.heap<i32>>> = %c1 : i32)
         linear_var_types([i32]) {
  omp.loop_nest (%iv) : i32 = (%lb) to (%ub) inclusive step (%c1) {
    // body uses %arg0, a real private allocatable
  }
}
```

In the translation, linear items that have a recipe would go through allocatePrivateVars/initPrivateVars/cleanupPrivateVars. LinearClauseProcessor would then only handle the linear part: start + iv*step and the last-iteration copy-back, applied to the private copy's data. Linear items without a recipe stay on the current path.

Open point: the translation can't look inside a Fortran descriptor, so it needs a way to get the data address. One option is a small optional region on the recipe or on the clause that yields it, which flang would fill with fir.load + fir.box_addr. The alternative needs no dialect change: privatize a with plain private and have flang emit the update and copy-back in the loop body, like lastprivate. That's simpler, but the item drops out of linear(...) and the simd linear information is lost.

Rough plan, as separate PRs:
1. MLIR: optional recipe and block args on the linear clause (interface, printer/parser, verifier), plus the data-address region.
2. Translation: reuse the privatization helpers for linear items that have a recipe.
3. Flang: generate the recipe for allocatable linear items (they're currently excluded in DSP), emit the new form, and remove the workaround from this PR.

Questions:
- Does linear carrying a privatizer recipe sound right to you? Should it be limited to descriptor types for now, or should all linear items move to it eventually?
- Should the data-address region live on omp.private or on the linear clause? Or would you prefer the no-dialect-change route?


https://github.com/llvm/llvm-project/pull/228827