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

Kareem Ergawy via All-commits all-commits at lists.llvm.org
Mon Mar 3 02:44:42 PST 2025


  Branch: refs/heads/users/ergawy/fix_simd_lastprivate_issue
  Home:   https://github.com/llvm/llvm-project
  Commit: 07ea43b1c42f04963678de2a3783e71b9b001647
      https://github.com/llvm/llvm-project/commit/07ea43b1c42f04963678de2a3783e71b9b001647
  Author: ergawy <kareem.ergawy at amd.com>
  Date:   2025-03-03 (Mon, 03 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`

This PR to 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 durectly
   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


More information about the All-commits mailing list