RFC: TableGen definition of OpenCL builtin functions

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

RFC: TableGen definition of OpenCL builtin functions

Oleg Smolsky via cfe-dev

RFC: TableGen definition of OpenCL builtin functions



# Introduction
OpenCL has a large number of builtin functions that are available to OpenCL C
users without explicitly declaring or including any header files.


# Current status
OpenCL builtins are currently declared in clang in lib/Headers/opencl-c.h and
the flag -finclude-default-header includes the header into the user's program.
This file is currently ~16K lines and 768K of data and declares ~13K function
declarations. This is slow to parse for every OpenCL program that is compiled.
Attempts to use PCH have been made to reduce the parsing time, at increased
cost of space. The resulting PCH file is several megabytes, which is too big
for some use cases.


An approach to improve the current situation was attempted in [1], to split the
header into smaller components. It seems this approach has several drawbacks
related to macros and PCH.


Another attempted improvement was made in [2], which was aimed directly at the
'convert' builtin, which has ~6000 overloads.


# This RFC
The approach in this RFC uses TableGen to declare the OpenCL builtins in a
concise manner. TableGen generates a trie and tables for recognising and
constructing the function declaration.  Clang then constructs the necessary
builtin function declarations when a regular name lookup fails. This approach
avoids the need to parse the opencl-c.h header and the tables themselves are
significantly smaller than the PCH file.


This follows a similar approach to Clang's current builtins, declared in
include/clang/Basic/Builtins.def.
Some reasons to go for a TableGen-based approach are:


1) We want the declarations to be more concise, which we can do with TableGen
but not with preprocessor macros.


2) The OpenCL builtins do not need a BuiltinID, nor any other special handling
in Clang, as their implementations are provided by the OpenCL vendor.


Although out of the scope of this RFC, the builtins in Builtins.def could be
migrated to a similar approach, there is already a comment in Builtins.def
about moving to TableGen (from 2007!).


The proposed solution can be viewed here https://reviews.llvm.org/D53023


# Next steps
This is still a work-in-progress patch as it is missing functionality and has
not been benchmarked for size/performance impact.  We are hoping to hear from
the wider clang community, as it might not only affect the OpenCL users.  In
particular, we expect the clang binary size will increase by roughly a few
hundred kilobytes.


Any feedback is welcome!


# References
[1] https://reviews.llvm.org/D51544
[2] https://reviews.llvm.org/D52457


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: TableGen definition of OpenCL builtin functions

Oleg Smolsky via cfe-dev

Hello,


I would quite like to see this in Clang at least for the OpenCL builtin functions. Potentially we could migrate other Builtins to use TableGen too?


- For OpenCL developers, do we have an agreement currently to use this approach?


- For  the developers outside of OpenCL community, do you see any issue with a small increase (a few hundred kilobytes) of the Clang binary due to an include of a TableGen-ed trie file? Also would anyone be interested in seeing other Builtins ported to this TableGen based approach?


Thanks in advance,

Anastasia




From: cfe-dev <[hidden email]> on behalf of Joey Gouly via cfe-dev <[hidden email]>
Sent: 02 November 2018 16:30
To: clang-dev developer list
Cc: nd; Sven Van Haastregt
Subject: [cfe-dev] RFC: TableGen definition of OpenCL builtin functions
 

RFC: TableGen definition of OpenCL builtin functions



# Introduction
OpenCL has a large number of builtin functions that are available to OpenCL C
users without explicitly declaring or including any header files.


# Current status
OpenCL builtins are currently declared in clang in lib/Headers/opencl-c.h and
the flag -finclude-default-header includes the header into the user's program.
This file is currently ~16K lines and 768K of data and declares ~13K function
declarations. This is slow to parse for every OpenCL program that is compiled.
Attempts to use PCH have been made to reduce the parsing time, at increased
cost of space. The resulting PCH file is several megabytes, which is too big
for some use cases.


An approach to improve the current situation was attempted in [1], to split the
header into smaller components. It seems this approach has several drawbacks
related to macros and PCH.


Another attempted improvement was made in [2], which was aimed directly at the
'convert' builtin, which has ~6000 overloads.


# This RFC
The approach in this RFC uses TableGen to declare the OpenCL builtins in a
concise manner. TableGen generates a trie and tables for recognising and
constructing the function declaration.  Clang then constructs the necessary
builtin function declarations when a regular name lookup fails. This approach
avoids the need to parse the opencl-c.h header and the tables themselves are
significantly smaller than the PCH file.


This follows a similar approach to Clang's current builtins, declared in
include/clang/Basic/Builtins.def.
Some reasons to go for a TableGen-based approach are:


1) We want the declarations to be more concise, which we can do with TableGen
but not with preprocessor macros.


2) The OpenCL builtins do not need a BuiltinID, nor any other special handling
in Clang, as their implementations are provided by the OpenCL vendor.


Although out of the scope of this RFC, the builtins in Builtins.def could be
migrated to a similar approach, there is already a comment in Builtins.def
about moving to TableGen (from 2007!).


The proposed solution can be viewed here https://reviews.llvm.org/D53023


# Next steps
This is still a work-in-progress patch as it is missing functionality and has
not been benchmarked for size/performance impact.  We are hoping to hear from
the wider clang community, as it might not only affect the OpenCL users.  In
particular, we expect the clang binary size will increase by roughly a few
hundred kilobytes.


Any feedback is welcome!


# References
[1] https://reviews.llvm.org/D51544
[2] https://reviews.llvm.org/D52457


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev