[PATCH] D51544: [OpenCL] Split opencl-c.h header

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added a comment.

In https://reviews.llvm.org/D51544#1230264, @asavonic wrote:

> In https://reviews.llvm.org/D51544#1229105, @Anastasia wrote:
>
> > > With this setup, we can compile opencl-c-common.h, opencl-c-fp16.h and
> > >  opencl-c-fp64.h into PCHs with one set of extensions/OpenCL version,
> > >  and use them for any other set of extensions/OpenCL version. Clang
> > >  will detect this and throw out an error, which can be safely disabled
> > >  by -fno-validate-pch option.
> >
> > However, keeping this as a permanent solution is unsafe. Because this way can result in unexpected errors to be silent out and allow erroneous configurations to be accepted successfully without any notification.
>
>
> Agree. LIT test in `test/Headers/opencl-c-header-split.cl` is supposed
>  to verify that common/fp16/fp64 headers do not use preprocessor macros
>  and it should catch most of the issues, but this is definitely not the
>  most robust solution.
>
> > So I am wondering if there is any plan to put a proper solution in place at some point?
>
> This solution can be improved if we implement `convert` and `shuffle`
>  as clang builtins with custom typechecking: these two builtins (with
>  all their overloadings) take ~90% of `opencl-c-common.h` and ~50% of
>  fp16/fp64 headers.
>
> However, this can be a non-trivial change: it is difficult to do a
>  proper mangling for clang builtins and rounding modes must be handled
>  as well.
>
> I'll take a few days to prototype this. If it turns out to be good in
>  terms of performance/footprint, we can drop this patch.


Btw, I was wondering if a target agnostic PCH is a viable solution to move forward too. Something that we discussed/prototyped during the HackerLab in EuroLLVM?


Repository:
  rC Clang

https://reviews.llvm.org/D51544