[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