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

Tom Eccles via All-commits all-commits at lists.llvm.org
Thu May 22 07:26:14 PDT 2025


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: e9cba3c8edca3dc805e82afbb482b3938cb96ae2
      https://github.com/llvm/llvm-project/commit/e9cba3c8edca3dc805e82afbb482b3938cb96ae2
  Author: Tom Eccles <tom.eccles at arm.com>
  Date:   2025-05-22 (Thu, 22 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 (#140092)

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