[all-commits] [llvm/llvm-project] 9543e9: [flang][OpenMP] Handle pre-detemined `lastprivate`...

[Kareem Ergawy via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 9543e9e9270e01f2c7311b571246c6ea105bcdb0
      https://github.com/llvm/llvm-project/commit/9543e9e9270e01f2c7311b571246c6ea105bcdb0
  Author: Kareem Ergawy <kareem.ergawy at amd.com>
  Date:   2025-03-07 (Fri, 07 Mar 2025)

  Changed paths:
    A flang/lib/Lower/OpenMP/ClauseFinder.h
    M flang/lib/Lower/OpenMP/ClauseProcessor.cpp
    M flang/lib/Lower/OpenMP/ClauseProcessor.h
    M flang/lib/Lower/OpenMP/DataSharingProcessor.cpp
    M flang/lib/Lower/OpenMP/OpenMP.cpp
    M flang/lib/Lower/OpenMP/Utils.cpp
    M flang/lib/Lower/OpenMP/Utils.h
    M flang/test/Lower/OpenMP/distribute-parallel-do-simd.f90
    M flang/test/Lower/OpenMP/lastprivate-iv.f90
    M flang/test/Lower/OpenMP/lastprivate-simd.f90
    M flang/test/Lower/OpenMP/parallel-wsloop-lastpriv.f90

  Log Message:
  -----------
  [flang][OpenMP] Handle pre-detemined `lastprivate` for `simd` (#129507)

This PR tries to fix `lastprivate` update issues in composite
constructs. In particular, pre-determined `lastprivate` symbols are
attached to the wrong leaf of the composite construct (the outermost
one). When using delayed privatization (should be the default mode in
the future), this results in trying to update the `lastprivate` symbol
in the wrong construct (outside the `omp.loop_nest` op).

For example, given the following input:
```fortran
!$omp target teams distribute parallel do simd collapse(2) private(y_max)
  do i=x_min,x_max
    do j=y_min,y_max
    enddo
  enddo
```

Without the fixes introduced in this PR, the `DataSharingProcessor`
tries to generate the `lastprivate` update ops in the `parallel` op
since this is the op for which the DSP instance is created.

The fix consists of 2 main parts:
1. Instead of creating a single DSP instance, one instance is created
for the leaf constructs that might need privatization (whether for
explicit, implicit, or pre-determined symbols).
2. When generating the `lastprivate` comparison ops, we don't directly
use the SSA values of the UBs and steps. Instead, we regenerated these
SSA values from the original loop bounds' expressions. We have to do
this to avoid using `host_eval` values in the `lastprivate` comparison
logic which is illegal.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications