[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