This is an archive of the discontinued LLVM Phabricator instance.

[OpenMP] Do not propagate match extensions to nested contexts
ClosedPublic

Authored by jdoerfert on Jan 31 2021, 10:12 AM.

Details

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.

Diff Detail

Event Timeline

jdoerfert created this revision.Jan 31 2021, 10:12 AM
jdoerfert requested review of this revision.Jan 31 2021, 10:12 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 31 2021, 10:12 AM

So I suppose D95765 can replace this patch, right?

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.

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?

Update docs

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.

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.

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 accepted this revision.Feb 1 2021, 3:20 PM

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

This revision is now accepted and ready to land.Feb 1 2021, 3:20 PM
This revision was landed with ongoing or failed builds.Mar 11 2021, 9:31 PM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptMar 11 2021, 9:31 PM