[all-commits] [llvm/llvm-project] 429000: [flang][OpenMP] use attribute for delayed privatiz...

Tom Eccles via All-commits all-commits at lists.llvm.org
Thu May 15 09:05:14 PDT 2025


  Branch: refs/heads/users/tblah/firstprivate-barrier-2
  Home:   https://github.com/llvm/llvm-project
  Commit: 4290004bb2bf9c7a978725262c0521902666fb06
      https://github.com/llvm/llvm-project/commit/4290004bb2bf9c7a978725262c0521902666fb06
  Author: Tom Eccles <tom.eccles at arm.com>
  Date:   2025-05-15 (Thu, 15 May 2025)

  Changed paths:
    M flang/lib/Lower/OpenMP/DataSharingProcessor.cpp
    M flang/lib/Lower/OpenMP/DataSharingProcessor.h
    M flang/test/Lower/OpenMP/lastprivate-allocatable.f90
    M flang/test/Lower/OpenMP/parallel-lastprivate-clause-scalar.f90
    M flang/test/Lower/OpenMP/same_var_first_lastprivate.f90

  Log Message:
  -----------
  [flang][OpenMP] use attribute for delayed privatization barrier

Fixes #136357

The barrier needs to go between the copying into firstprivate variables
and the initialization call for the OpenMP construct (e.g. wsloop).
There is no way of expressing this in MLIR because for delayed
privatization that is all implicit (added in MLIR->LLVMIR conversion).

The previous approach put the barrier immediately before the wsloop (or
similar). For delayed privatization, the firstprivate copy code would
then be inserted after that, opening the possibility for the race
observed in the bug report.

This patch solves the issue by instead setting an attribute on the mlir
operation, which will instruct openmp dialect to llvm ir conversion to
insert a barrier in the correct place.



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