[llvm-branch-commits] [flang] [llvm] [flang][OpenMP] Don't treat different runtime conditions as subsets (PR #233493)

Sairudra More via llvm-branch-commits llvm-branch-commits at lists.llvm.org
Tue Oct 20 02:58:04 PDT 2026


================
@@ -172,6 +172,16 @@ static bool isStrictSubset(const VariantMatchInfo &VMI0,
   for (unsigned Bit : VMI0.RequiredTraits.set_bits())
     if (!VMI1.RequiredTraits.test(Bit))
       return false;
+  // Different runtime conditions share a trait, so compare them as well.
+  // A runtime condition can be left out of the traits but keep its key.
+  if (!VMI0.UserCondition.empty() && VMI0.UserCondition != VMI1.UserCondition)
----------------
Saieiei wrote:

At c11d452e, this selects BARRIER when both arguments are true, while the parent `8023c055` selects TASKWAIT. The first selector is a strict subset of the third, leaving the second and third tied at 5, so clause order should select TASKWAIT.

```fortran
subroutine three(a, b)
  logical, intent(in) :: a, b
  !$omp metadirective &
  !$omp& when(user={condition(a)}, implementation={vendor(score(4): llvm)}: taskyield) &
  !$omp& when(user={condition(b)}, device={kind(host)}, implementation={vendor(score(3): llvm)}: taskwait) &
  !$omp& when(user={condition(a)}, device={kind(host)}, implementation={vendor(score(3): llvm)}: barrier)
end subroutine
```

`getBestVariantMatchForContext` only compares each candidate with the current best, so the third replaces the first without being compared with the second.

This seems related to your [planned strict-subset follow-up](https://github.com/llvm/llvm-project/pull/231668#issuecomment-6224344881). Should this case be fixed here or tracked in that follow-up?

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


More information about the llvm-branch-commits mailing list