This is an archive of the discontinued LLVM Phabricator instance.

[OpenCL] Prevent adding extension pragma by default
ClosedPublic

Authored by Anastasia on Feb 19 2021, 7:47 AM.

Details

Summary

Currently, extension pragma is always added when new OpenCL option (extension or feature) is added to the frontend. This change adds a new field for the options that allows specifying the need for the pragmas.

For backward compatibility, the pragmas are added for all extensions prior to OpenCL 3.0.

For OpenCL 3.0 features and future extensions (those that are documented in the unified spec only), the pragmas is not to be added unless they are explicitly requested and their behavior is sufficiently well explained.

Diff Detail

Event Timeline

Anastasia created this revision.Feb 19 2021, 7:47 AM
Anastasia requested review of this revision.Feb 19 2021, 7:48 AM

Thanks! I review is shortly. As for now, I also was doing some refactoring: https://reviews.llvm.org/D97058. Check-clang passes, as I see there are no conflicts for now.

svenvh added inline comments.Feb 19 2021, 9:24 AM
clang/include/clang/Basic/OpenCLExtensions.def
24

typo

65

You're introducing a double space.

clang/lib/Parse/ParsePragma.cpp
785

I fail to understand why this is needed, so perhaps this needs a bit more explanation. Extensions that should continue to support pragmas already have their WithPragma field set to true via OpenCLExtensions.def. Why do we need to dynamically modify the field?

azabaznov added inline comments.Feb 19 2021, 10:31 AM
clang/include/clang/Basic/OpenCLExtensions.def
71

I think core and optional core features do not require pragma too. So for example 3d image writes or fp64 do not require pragma in OpenCL C 2.0. Isn't that so?

clang/test/SemaOpenCL/extension-version.cl
217

Again about core or optional core: don't you feel that current diagnostic is good already (https://godbolt.org/z/Kcjdvr)?

Anastasia added inline comments.Feb 19 2021, 11:19 AM
clang/include/clang/Basic/OpenCLExtensions.def
71

Well to be honest nothing seems to need pragma but we have to accept it for the backward compatibility. :)

In case of the core features if pragma would have been useful we would have to still accept it for the backward compatibility even if the feature became core.

clang/lib/Parse/ParsePragma.cpp
785

It is a bit twisty here to be honest. Because we have also introduced the pragma begin and end that would add pragma enable/disable by default. So any extension added dynamically using begin/end would have to accept the pragma enable/disable.

https://clang.llvm.org/docs/UsersManual.html#opencl-extensions

But in the subsequent patches, I hope to remove this because I just don't see where it is useful but it is very confusing.

clang/test/SemaOpenCL/extension-version.cl
217

First of all with current approach, clang will only provide the diagnostic if an extra warning flag is passed. By default it accepts the pragma silently.

Secondly, to provide consistency clang will either need to know all of the features in the standard even if they are added in the libraries or otherwise, it will provide inconsistent diagnostics - for features added into clang we provide this diagnostic but for the others, we provide the diagnostics that you refer to. I appreciate that we already have the behavior very inconsistent but it is not great.

Another aspect is that the diagnostic we have currently indicates that the pragma is somehow legal (known) and might do something but in fact we never intended it to exist and never intended that frontend would do something with it. So I prefer to have consistency here with the regular diagnostics about the pragmas and indicate that the pragma is unknown. This just makes things simpler for everyone and avoids redundancy in the language too.

FYI this change is generally driving towards deprecation of the extension pragmas overall.

azabaznov added inline comments.Feb 20 2021, 12:12 AM
clang/include/clang/Basic/OpenCLExtensions.def
71

I'm just wondering if this new field needed in the file to maintain backward compatibility. Maybe we can highlight OpenCL C 3.0 features with some other way? Is it seems that check for name starting with "__opencl_c" is a bad idea?

clang/lib/Parse/ParsePragma.cpp
785

Is it ok not to track this situation here:

#pragma OPENCL EXTENSION __opencl_c_feature : begin
#pragma OPENCL EXTENSION __opencl_c_feature: end

This is some of a corner case, but still...

Anastasia added inline comments.Feb 22 2021, 8:10 AM
clang/include/clang/Basic/OpenCLExtensions.def
71

Not sure I understand you here but I don't think that we should add extension pragmas any longer at all even for the new extensions. FYI I am planning to add guidelines for that in https://reviews.llvm.org/D97072. Maybe it helps to clarify the idea?

clang/lib/Parse/ParsePragma.cpp
785

I see. I am not sure what should happen here - I guess we should give an error? Although for earlier versions than OpenCL 3.0 this should probably be accepted?

Perhaps we can create a PR for this for now...

Anastasia updated this revision to Diff 325734.Feb 23 2021, 4:02 AM

Fixed typo and extra space.

Some relatively minor comments, overall direction seems good to me.

clang/include/clang/Basic/OpenCLOptions.h
67–70

In OpenCLExtensions.def, the order is: pragma, avail, core, opt.
In this class it is: avail, core, opt, pragma (for both the attributes and the constructor parameters).

There are very few usages of this, so the impact of this inconsistency is minor. However, because the conversion between unsigned and bool is implicit an error might go unnoticed for a long time.

clang/lib/Basic/OpenCLOptions.cpp
89–91

This could be done using insert_or_assign(key, value).

clang/lib/Basic/Targets.cpp
738

For consistency with OpenCLExtensions.def.

azabaznov added inline comments.Feb 25 2021, 12:59 AM
clang/include/clang/Basic/OpenCLExtensions.def
71

I mean that you could modify OpenCLOptions::isWithPragma that it will check if extension/feature was introduced in OpenCL C 3.0. If that's the case then no pragma needed. This new field pragma looks redundant as it is set to true only for OpenCL C 3.0 features. However, it may be more cosmetic concern...

clang/lib/Parse/ParsePragma.cpp
785

Oh, I think we can ignore this as double underscored identifiers are reserved. It's not expected that users will declare new features.

I see the update regaring this functionality on github issue: https://github.com/KhronosGroup/OpenCL-Docs/issues/82#issuecomment-785496025. Is it a right way to reflect this information in`OpenCLExtensions.def`?

Anastasia updated this revision to Diff 327204.Mar 1 2021, 11:17 AM
  • Reorder fields,
  • make constructor parameters explicit
  • use insert_or_assign member of StringMap.

I see the update regaring this functionality on github issue: https://github.com/KhronosGroup/OpenCL-Docs/issues/82#issuecomment-785496025. Is it a right way to reflect this information in`OpenCLExtensions.def`?

The update only suggests a possible route and I don't want to block on it until there is a final decision. But if that becomes final, it is unlikely we will do something different. All the legacy pragmas will need to be accepted anyway.

clang/include/clang/Basic/OpenCLExtensions.def
71

You are right that it is only set to true for the OpenCL 3.0 features right now but the idea is to provide flexibility to set the pragma for every new extension/feature being added in the future instead of always adding the pragma unconditionally. This is why (I presume) we ended up with pragma for every extension in the first place. No matter that half of them were not used at all.

Also, there is nothing fundamentally different between extensions and features. The difference is purely wording in the spec. So I prefer us to use the same mechanisms for both.

clang/lib/Parse/ParsePragma.cpp
785

Yes, I think this is mainly used by tool developers.

Thanks for working on this. LGTM in general. I'll let Marco comment on the latest changes.

Anastasia updated this revision to Diff 327400.Mar 2 2021, 3:11 AM

Reuploaded with changes from the 1st review round.

mantognini accepted this revision.Mar 2 2021, 3:14 AM

LGTM, thanks for the update.

This revision is now accepted and ready to land.Mar 2 2021, 3:14 AM
This revision was landed with ongoing or failed builds.Mar 3 2021, 7:03 AM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptMar 3 2021, 7:03 AM