asavonic added a comment.

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.


Repository:
  rC Clang

https://reviews.llvm.org/D51544



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to