[OpenMP] Do not propagate match extensions to nested contexts

[jdoerfert]

Summary

If we have nested declare variant context, it doesn't make sense to
inherit the match extension from the parent. Instead, just skip it.

[tianshilei1992]

So I suppose D95765 can replace this patch, right?

[jdoerfert]

In D95764#2532875, @tianshilei1992 wrote:

So I suppose D95765 can replace this patch, right?

I think we want both. Propagating match clauses doesn't make sense to me so we should never do it.

[tianshilei1992]

In D95764#2532877, @jdoerfert wrote:

In D95764#2532875, @tianshilei1992 wrote:

So I suppose D95765 can replace this patch, right?

I think we want both. Propagating match clauses doesn't make sense to me so we should never do it.

Is there any place documenting the propagation?

[jdoerfert]

Update docs

[jdoerfert]

In D95764#2532908, @tianshilei1992 wrote:

In D95764#2532877, @jdoerfert wrote:

In D95764#2532875, @tianshilei1992 wrote:

So I suppose D95765 can replace this patch, right?

I think we want both. Propagating match clauses doesn't make sense to me so we should never do it.

Is there any place documenting the propagation?

The standard documents that nested contexts will inherit the selectors, in a specific way. given that this is an llvm extension, we can overwrite that though. I added the documentation changes now.

[JonChesterfield]

I would have expected a nested match statement to hit on a subset of those that matched in the parent.

If (match x64)
If (match Intel)

• expect x64 and intel to be true here

I think that's how the normal openmp variant match works. Why do we want to diverge from that for (all?) extensions? It would make for a semantic break if one of the extensions was standardised.

[jdoerfert]

In D95764#2532927, @JonChesterfield wrote:

I would have expected a nested match statement to hit on a subset of those that matched in the parent.

If (match x64)
If (match Intel)

• expect x64 and intel to be true here

I think that's how the normal openmp variant match works.

It is.

Why do we want to diverge from that for (all?) extensions?

For the same reason we have match_any and other things that modify the standard behavior, it is useful or even necessary to solve certain problems.

It would make for a semantic break if one of the extensions was standardised.

Yes and no. Like a breaking change in the standard, that could happen on a conceptual level. However, if the standard would adopt part of the match_any
semantics, it would not assume it to be in the extension trait set. Doing so would introduce problems for downstream extensions which are basically
breaking changes. That said, you have to remember that the semantic of match_any (and match_none) was made up for LLVM and is already changing the
behavior of the variant selector compared to the default described in the standard. The argument of this patch is that this made up semantics should be
tweaked. FWIW, when I added the extension I haven't had implemented the selector inheritance yet, so at that point there was no practical difference.

[JonChesterfield]

That sounds reasonable. We can probably expect features to be renamed and semantically adjusted on their way to standardisation anyway.

clang/include/clang/Basic/AttrDocs.td

.. code-block:: none
     match_none
     disable_implicit_base
     allow_templates
 
 The match extensions change when the *entire* context selector is considered a
 match for an OpenMP context. The default is ``all``, with ``none`` no trait in the
 selector is allowed to be in the OpenMP context, with ``any`` a single trait in
 both the selector and OpenMP context is sufficient. Only a single match
-extension trait is allowed per context selector.
+extension trait is allowed per context selector. Note that match extensions are
+not propagated to nested selectors like the standard defines it for other traits.
 The disable extensions remove default effects of the ``begin declare variant``
 applied to a definition. If ``disable_implicit_base`` is given, we will not
 introduce an implicit base function for a variant if no base function was
 found. The variant is still generated but will never be called, due to the
 absence of a base function and consequently calls to a base function.
 The allow extensions change when the ``begin declare variant`` effect is
 applied to a definition. If ``allow_templates`` is given, template function
 definitions are considered as specializations of existing or assumed template

clang/lib/Parse/ParseOpenMP.cpp

for (OMPTraitSet &Set : TI.Sets) {
       for (const OMPTraitSelector &ParentSelector : ParentSet.Selectors) {
         bool MergedSelector = false;
         for (OMPTraitSelector &Selector : Set.Selectors) {
           if (Selector.Kind != ParentSelector.Kind)
             continue;
           MergedSelector = true;
           for (const OMPTraitProperty &ParentProperty :
                ParentSelector.Properties) {
+            // Do not propagate match extensions to nested contexts.
+            if (ParentProperty.Kind == llvm::omp::TraitProperty::
+                                           implementation_extension_match_any ||
+                ParentProperty.Kind == llvm::omp::TraitProperty::
+                                           implementation_extension_match_all ||
+                ParentProperty.Kind == llvm::omp::TraitProperty::
+                                           implementation_extension_match_none)
+              continue;
             bool MergedProperty = false;
             for (OMPTraitProperty &Property : Selector.Properties) {
               // Ignore "equivalent" properties.
               if (Property.Kind != ParentProperty.Kind)
                 continue;
 
               // If the kind is the same but the raw string not, we don't want
               // to skip out on the property.

clang/test/OpenMP/begin_declare_variant_nested_propagation.c

+// RUN: %clang_cc1 -triple=x86_64-pc-win32 -verify -fopenmp -x c -std=c99 -fms-extensions -Wno-pragma-pack %s
+// expected-no-diagnostics
+
+#pragma omp begin declare variant match(implementation={extension(match_any)})
+#pragma omp begin declare variant match(device = {vendor(cray, ibm)})
+ this is never reached, we cannot have a cray ibm compiler hybrid, I hope.
+#pragma omp end declare variant
+#pragma omp end declare variant