I think the question is whether Clang is able to decide whether an extension/feature is supported based on target (cpu, os, environment, etc.).
If we take a look at the extensions/optional core features:
// OpenCL 2.0
// Clang Extensions.
I think most of them can be determined by Clang based on target, e.g. fp64, fp16, atomics, byte_adderssable_store, 3d_image_writes since they are mostly hardware features.
I think gl_sharing, gl_event, d3d10_sharing do not matter since they have no effect on language/builtin functions.
gl_msaa_sharing should be judged only based on hardware capability, not the availability of gl, since that’s what matters to the builtin functions.
The advantage of this approach is to save the user the burden of setting command line options to turn on/off these extensions/features. For flexibility, we may also consider adding an option –fsupport-cl-ext:extension to allow turning on/off certain extensions/features.