[PATCH] D51544: [OpenCL] Split opencl-c.h header
Anastasia Stulova via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Fri Sep 7 07:25:32 PDT 2018
Anastasia added a comment.
In https://reviews.llvm.org/D51544#1224780, @asavonic wrote:
> In https://reviews.llvm.org/D51544#1224730, @Anastasia wrote:
>
> > It seems generally good to partition this big header but I am trying to understand what problem is it trying to solve now?
>
>
> Main motivation is to reduce memory footprint by factoring out everything that is 'common' between PCHs compiled for different targets (CL1.2/2.0 and spir/spir64).
>
> > So if we want to add these 2 devices, we now need 4*2 different PCHs,
> > since every combination of -cl-std and -triple must be compiled twice
> > with different OpenCL extensions defines.
> >
> > Size of each PCH is 2.5M, so we need ~20M of memory to store our
> > PCHs. If we want to add more devices or support another OpenCL C
> > version, the size will double.
>
> This also allows to do 'partial' pre-compilation, where 'common' part is pre-compiled into a single target independent PCH, and plain header is used for all target-specific things.
> In this case, you no longer need to maintain different target-specific PCHs and this greatly simplifies the whole process.
>
> > opencl-c-platform.h (5K LOC) must still be pre-compiled for each
> > supported combination, but since it is a lot smaller (~0.5M vs
> > original 2.5M), it is not that bad. Or we can sacrifice some
> > performance and leave this header without pre-compilation: large
> > portion of opencl-c-platform.h contains vendor extensions, so it will
> > be removed by preprocessor anyway.
Currently the main header still contains everything, so the size of the PCH won't change. So I was wondering what would be the way to avoid this... other than adding explicit `#include`.
Repository:
rC Clang
https://reviews.llvm.org/D51544
More information about the cfe-commits
mailing list