[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