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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
