This is an archive of the discontinued LLVM Phabricator instance.

[OpenCL] Remove FIXME in getOpenCLFeatureDefines
Needs ReviewPublic

Authored by svenvh on Feb 12 2021, 3:13 AM.

Details

Summary

The suggestion in D92277 was to move OpenCLOptions into LanguageOptions, but
this is not viable. Sema's LangOpts is immutable, and embedding
OpenCLOptions into LangOpts would make OpenCLOptions immutable too.
This is incompatible with handling of pragmas that alter the
OpenCLOptions during parsing/sema.

Perhaps there might be another solution, so putting this up for discussion with
@Anastasia and @azabaznov to start with.

Diff Detail

Event Timeline

svenvh created this revision.Feb 12 2021, 3:13 AM
svenvh requested review of this revision.Feb 12 2021, 3:13 AM

The suggestion in D92277 was to move OpenCLOptions into LanguageOptions, but

this is not viable. Sema's LangOpts is immutable, and embedding
OpenCLOptions into LangOpts would make OpenCLOptions immutable too.
This is incompatible with handling of pragmas that alter the
OpenCLOptions during parsing/sema.

That's right in general OpenCLOptions should become a part of LangOptions as they are the same conceptually. CompilerInvocation has LangOptions as non-const member and it sets many of its fields. So it could do the same for OpenCL specific options as it also contains TargetOptions with OpenCLFeaturesMap so it know what the targets support and, therefore, has the full information needed to complete the right setup.

I agree dynamic modifications of OpenCLOptions via pragmas makes things more complicated. However, we could do something similar to CurFPFeatures in Sema that duplicates some of floating point options of the LangOptions and provides the functionality of dynamic modification via pragmas too. The OpenCL use case is exactly the same. In reality, very few options would need the pragma so the number of items in that extra data structure would be very small. But unfortunately, this is not where we are right now yet. Because with time a lot of pragma uses have been added without good justification. So perhaps it is not a practical refactoring at the moment. But maybe it is something we could still do in the future if we modify the pragma use cases?