[all-commits] [llvm/llvm-project] 0e5633: [OMPIRBuilder] always leave PARALLEL via the same ...

[Tom Eccles via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 0e5633fcd984b54acc071c2c982c1ff4691aa10f
      https://github.com/llvm/llvm-project/commit/0e5633fcd984b54acc071c2c982c1ff4691aa10f
  Author: Tom Eccles <tom.eccles at arm.com>
  Date:   2025-11-27 (Thu, 27 Nov 2025)

  Changed paths:
    M clang/test/OpenMP/cancel_codegen.cpp
    M clang/test/OpenMP/critical_codegen.cpp
    M clang/test/OpenMP/critical_codegen_attr.cpp
    M clang/test/OpenMP/irbuilder_nested_parallel_for.c
    M clang/test/OpenMP/masked_codegen.cpp
    M clang/test/OpenMP/master_codegen.cpp
    M clang/test/OpenMP/nested_loop_codegen.cpp
    M clang/test/OpenMP/ordered_codegen.cpp
    M clang/test/OpenMP/parallel_codegen.cpp
    M flang/test/Integration/OpenMP/parallel-private-reduction-worstcase.f90
    M llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
    M llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
    M llvm/test/Transforms/OpenMP/parallel_region_merging.ll
    M llvm/unittests/Frontend/OpenMPIRBuilderTest.cpp
    M mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp
    M mlir/test/Target/LLVMIR/openmp-barrier-cancel.mlir
    M mlir/test/Target/LLVMIR/openmp-cancel.mlir
    M mlir/test/Target/LLVMIR/openmp-cancellation-point.mlir
    M mlir/test/Target/LLVMIR/openmp-outline-infinite-loop.mlir
    M mlir/test/Target/LLVMIR/openmp-parallel-reduction-multiblock.mlir
    M mlir/test/Target/LLVMIR/openmp-reduction-array-sections.mlir
    M mlir/test/Target/LLVMIR/openmp-reduction-init-arg.mlir
    M mlir/test/Target/LLVMIR/openmp-reduction-sections.mlir

  Log Message:
  -----------
  [OMPIRBuilder] always leave PARALLEL via the same barrier (#164586)

A barrier will pause execution until all threads reach it. If some go to
a different barrier then we deadlock. This manifests in that the
finalization callback must only be run once. Fix by ensuring we always
go through the same finalization block whether the thread in cancelled
or not and no matter which cancellation point causes the cancellation.

The old callback only affected PARALLEL, so it has been moved into the
code generating PARALLEL. For this reason, we don't need similar changes
for other cancellable constructs. We need to create the barrier on the
shared exit from the outlined function instead of only on the cancelled
branch to make sure that threads exiting normally (without cancellation)
meet the same barriers as those which were cancelled. For example,
previously we might have generated code like

```
...
  %ret = call i32 @__kmpc_cancel(...)
  %cond = icmp eq i32 %ret, 0
  br i1 %cond, label %continue, label %cancel

continue:
  // do the rest of the callback, eventually branching to %fini
  br label %fini

cancel:
  // Populated by the callback:
  // unsafe: if any thread makes it to the end without being cancelled
  // it won't reach this barrier and then the program will deadlock
  %unused = call i32 @__kmpc_cancel_barrier(...)
  br label %fini

fini:
  // run destructors etc
  ret
```

In the new version the barrier is moved into fini. I generate it *after*
the destructors because the standard describes the barrier as occurring
after the end of the parallel region.

```
...
  %ret = call i32 @__kmpc_cancel(...)
  %cond = icmp eq i32 %ret, 0
  br i1 %cond, label %continue, label %cancel

continue:
  // do the rest of the callback, eventually branching to %fini
  br label %fini

cancel:
  br label %fini

fini:
  // run destructors etc
  // safe so long as every exit from the function happens via this block:
  %unused = call i32 @__kmpc_cancel_barrier(...)
  ret
```

To achieve this, the barrier is now generated alongside the finalization
code instead of in the callback. This is the reason for the changes to
the unit test.

I'm unsure if I should keep the incorrect barrier generation callback
only on the cancellation branch in clang with the OMPIRBuilder backend
because that would match clang's ordinary codegen. Right now I have
opted to remove it entirely because it is a deadlock waiting to happen.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications