[cfe-dev] [RFC][OpenCL] Allow users to add supported OpenCL extensions by pragma

[C Bergström via cfe-dev]

On Mon, Jun 27, 2016 at 10:28 PM, Sumner, Brian <Brian.Sumner at amd.com> wrote:
> Christopher,  we can certainly modify clang, and have.  But then we have to carry those modifications around and try to get them into the clang code base.  Is it OK for clang to carry around every OpenCL vendor's vendor specific additions?  AMD has quite a few extensions, and so do Intel, Qualcomm, and others.   Wouldn't it be better for clang to provide a mechanism to allow extensions to be defined in a way that avoids clang having to carry around each and every one of those vendor extensions?
>
> Alexey, this proposal does change the behavior of the compiler.  It informs clang that there is an OpenCL extension that can be enabled and disabled whose name was not known at the time clang was built.  After being registered, clang must process enable and disable pragmas for the new extension exactly as it does the built-in KHR extensions.

I think this is two questions and I'm no authority on OpenCL, but my
general views

1) Should clang accept vendor specific extensions - Not my call, but I
think if they are generally valuable to the community - why not

2) Should the clang codebase be designed in a way to accommodate
vendor extensions.. Current proposal is to add a directive, is there
another way to accomplish this?

Could all this be refactored into something that would fit into a header?
Make a directory called OpenCL/extensions/<vendor>ocl.hpp

This could get complicated if Vendor A's extensions conflict with
Vendor B's.. There's also the case of common extensions that could be
aliased..
----------
3) If clang devs don't want vendor extensions - how expensive is it
really to carry these patches? Is it *really* that expensive in terms
of development?
----------
To use cmake as a comparison and it's not 1:1 exactly, but it's something..

cmake tries to do the "right thing" for every compiler it supports.
This means that every compiler and target ends up getting some level
of specific configuration. In general, the amount of extensions you're
proposal probably won't be the end of the world if accepted.

>From my non-vote-nobody-cares - I'd be way happier with a patch that
turned this into a build option than a pragma (hack). This would also
allow others to evaluate your extension and users to make a compatible
build (in theory)

The best technical argument I can come up against this directive is -
When you create a blanket directive like this, which in tern accepts
something it doesn't know about.. How do you correctly do sema on
that? One of clang's strongest points is the semantic analysis... Does
this solution impact that at all..

Directive seems like a work-around and not a true solution in this case..