[llvm] [OpenMPOpt] Fix incorrect end-of-kernel barrier removal (PR #65670)

Daniel Woodworth via llvm-commits llvm-commits at lists.llvm.org
Mon Sep 11 12:14:35 PDT 2023


================
@@ -2676,17 +2676,19 @@ struct AAExecutionDomainFunction : public AAExecutionDomain {
       if (!ED.EncounteredAssumes.empty() && !A.isModulePass())
         return;
 
-      // We can remove this barrier, if it is one, or all aligned barriers
-      // reaching the kernel end. In the latter case we can transitively work
-      // our way back until we find a barrier that guards a side-effect if we
-      // are dealing with the kernel end here.
+      // We can remove this barrier, if it is one, or aligned barriers reaching
+      // the kernel end (if CB is nullptr). Aligned barriers reaching the kernel
+      // end may have other successors besides the kernel end (especially if
+      // they're in loops) with non-local side-effects, so those barriers can
+      // only be removed if they also only reach the kernel end. If those
+      // barriers have other barriers reaching them, those can be transitively
+      // removed as well.
       if (CB) {
         DeletedBarriers.insert(CB);
         A.deleteAfterManifest(*CB);
         ++NumBarriersEliminated;
         Changed = ChangeStatus::CHANGED;
       } else if (!ED.AlignedBarriers.empty()) {
----------------
dwoodwor-intel wrote:

I've added the requested testcases in my update.

With this new updated the three barriers in `multiple_blocks_functions_kernel_effects_0` are back to being removed, but is this the correct behavior? It seems to me that we should preserve at least one of the barriers between the `barrier_then_write0` calls and the `write_then_barrier0` call.

https://github.com/llvm/llvm-project/pull/65670


More information about the llvm-commits mailing list