This is an archive of the discontinued LLVM Phabricator instance.

[OpenCL] Implement extended subgroups fully in headers
ClosedPublic

Authored by Anastasia on Nov 27 2020, 7:20 AM.

Details

Summary

Extended subgroups extensions were added in https://reviews.llvm.org/D79781, however, in the unpublished spec there is no pragma mentioned anywhere and therefore adding it is incorrect. This should be fixed ideally before the spec is published to avoid a wide impact on the developers.

Considering that the extensions are implemented in headers and libraries there is no point to add it into the main Clang code. Therefore the macro definitions are now moved to the internal header. The macros should only be defined if the functionality is available. This makes the flow more consistent for developers as without the header the functions are not declared and therefore any kernel code calling them won't be compiled successfully.

More details about the effort on correcting the extension implementation can be found in: https://reviews.llvm.org/D91531

Diff Detail

Event Timeline

Anastasia created this revision.Nov 27 2020, 7:20 AM
Anastasia requested review of this revision.Nov 27 2020, 7:20 AM
svenvh accepted this revision.Dec 1 2020, 3:45 AM

LGTM.

This revision is now accepted and ready to land.Dec 1 2020, 3:45 AM
PiotrFusik added a comment.EditedDec 1 2020, 4:08 AM

The specification for these extensions was edited by Ben Ashbaugh @Intel. I've asked him about this change.

The specification for these extensions was edited by Ben Ashbaugh @Intel. I've asked him about this change.

Sure. Thanks! Happy to hold off committing for a few days to see if Ben has any feedback.

The specification for these extensions was edited by Ben Ashbaugh @Intel. I've asked him about this change.

Sure. Thanks! Happy to hold off committing for a few days to see if Ben has any feedback.

FYI, I have discussed this with Ben offline and he doesn't seem to have any objections on the approach. I will keep this open for another week to see if there is any detailed feedback from anyone.

PiotrFusik requested changes to this revision.Dec 4 2020, 8:10 AM
PiotrFusik added inline comments.
clang/lib/Headers/opencl-c-base.h
17–23

These are currently defined as "1": https://godbolt.org/z/MnoWeo
Is the change to blank intentional?
This should be tested.

This revision now requires changes to proceed.Dec 4 2020, 8:10 AM
Anastasia added inline comments.Dec 8 2020, 7:48 AM
clang/lib/Headers/opencl-c-base.h
17–23

Thanks! I think the spec doesn't specify the values but only says that the macros are defined

Every extension which affects the OpenCL language semantics, syntax or adds built-in functions tothe language must create a preprocessor #define that matches the extension name string. This #define would be available in the language if and only if the extension is supported on a givenimplementation.

However, I think it makes sense to set the value 1 to align with the other extensions that are added by clang.

PiotrFusik added inline comments.Dec 8 2020, 8:05 AM
clang/lib/Headers/opencl-c-base.h
17–23

I think the spec doesn't specify the values but only says that the macros are defined

Yes, confirmed with Ben:

I don’t think we’ve said anything about the extension #defines, but for the OpenCL C 3.0 feature test macros we required that they are defined to a value for precisely this reason (#if used instead of #ifdef):

In OpenCL C 3.0 or newer, feature macros must expand to the value 1 if the feature macro is defined by the OpenCL C compiler. A feature macro must not be defined if the feature is not supported by the OpenCL C compiler. A feature macro may expand to a different value in the future, but if this occurs the value of the feature macro must compare greater than the prior value of the feature macro.

Anastasia updated this revision to Diff 310227.Dec 8 2020, 8:13 AM
  • Set all macros to value 1
This revision is now accepted and ready to land.Dec 8 2020, 8:39 AM
Anastasia added inline comments.Dec 8 2020, 9:42 AM
clang/lib/Headers/opencl-c-base.h
17–23

FYI, OpenCL 3.0 only determines the values for the feature macro but not the extension macro. Perhaps it's worth doing this for both?

This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptDec 10 2020, 8:41 AM