This is an archive of the discontinued LLVM Phabricator instance.

[OpenCL] Allow undefining header-only features
ClosedPublic

Authored by svenvh on Jan 9 2023, 9:11 AM.

Details

Summary

opencl-c-base.h always defines 5 particular feature macros for
SPIR-V, making it impossible to disable those features.

To allow disabling any of those features, let the header recognize
__undef_<feature> macros. The user can then pass the
-D__undef_<feature> flag on the command line to disable a specific
feature. The __undef macro could potentially also be set from
-cl-ext=-feature, but for now only change the header and only
provide __undef macros for the 5 features that are always enabled in
opencl-c-base.h.

This is an alternative to https://reviews.llvm.org/D137652

Diff Detail

Event Timeline

svenvh created this revision.Jan 9 2023, 9:11 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 9 2023, 9:11 AM
svenvh requested review of this revision.Jan 9 2023, 9:11 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 9 2023, 9:11 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript
Anastasia accepted this revision.Jan 11 2023, 4:36 AM

LGTM, thanks!

Btw I wonder if in the future we could add some error or warning in case someone uses the same approach for frontend specific features, i.e.

#ifdef __undef___opencl_c_generic_address_space
#error "Feature __opencl_c_generic_address_space can only be disabled via -cl-ext flag"
#endif
This revision is now accepted and ready to land.Jan 11 2023, 4:36 AM

Btw I wonder if in the future we could add some error or warning in case someone uses the same approach for frontend specific features, i.e.

#ifdef __undef___opencl_c_generic_address_space
#error "Feature __opencl_c_generic_address_space can only be disabled via -cl-ext flag"
#endif

Interesting idea, but I'm a bit hesitant of doing so:
It increases the size of opencl-c-base.h so it will take longer to parse, which will affect every OpenCL compilation. Luckily we can avoid that cost if we keep the __undef_ mechanism an internal solution, which it will be once we let -cl-ext=-feature generate __undef_ macros for extensions that are not in OpenCLExtensions.def. So longer term users will never have to pass __undef_ macros.

Btw I wonder if in the future we could add some error or warning in case someone uses the same approach for frontend specific features, i.e.

#ifdef __undef___opencl_c_generic_address_space
#error "Feature __opencl_c_generic_address_space can only be disabled via -cl-ext flag"
#endif

Interesting idea, but I'm a bit hesitant of doing so:
It increases the size of opencl-c-base.h so it will take longer to parse, which will affect every OpenCL compilation. Luckily we can avoid that cost if we keep the __undef_ mechanism an internal solution, which it will be once we let -cl-ext=-feature generate __undef_ macros for extensions that are not in OpenCLExtensions.def. So longer term users will never have to pass __undef_ macros.

Ok that would be better indeed. Btw I hope we won't have that many feature macros that it would be too long to parse those. :(

This revision was landed with ongoing or failed builds.Jan 16 2023, 3:32 AM
This revision was automatically updated to reflect the committed changes.