[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