<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size: 12pt; color: rgb(0, 0, 0); font-family: Calibri,Helvetica,sans-serif,"EmojiFont","Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;" dir="ltr">
<p style="margin-top:0;margin-bottom:0">Hi Andrew,</p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0">Potential problems with this approach are:</p>
<p style="margin-top:0;margin-bottom:0">- The maintenance costs as it's harder to modify Clang than just change the header in case we want to extend the list of builtins or modify them. Meaning that you have to add logic to clang to handle what is essentially
just a list of declarations. Clang builtins weren't really intended to solve this problem.</p>
<p style="margin-top:0;margin-bottom:0">- It is more risky in terms of bugs because it might not be easy to cover all use cases.<br>
</p>
<p style="margin-top:0;margin-bottom:0">- Affects parsing time to check all the extra switch cases.
<br>
</p>
<p style="margin-top:0;margin-bottom:0">- <span>We will need to replace the builtins from the header with macros aliasing Clang builtins. I find macros really bad in terms of error reporting. But also they will still need to be parsed.</span></p>
<p style="margin-top:0;margin-bottom:0"><span><br>
</span></p>
<p style="margin-top:0;margin-bottom:0"><span>Also something important to consider is the impact on parsing for other languages, i.e. C/C++. I think we should evaluate this carefully. Do you have any numbers for this already?</span><br>
</p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0">My team has a slightly different solution to this problem. It is based on generation of tries. Something similar to attribute parsing, see generated
<span>AttrParsedAttrKinds.inc</span>. Unfortunately it's not in a shape that we can currently share. But it should not take longer than 2-3 weeks to upload a prototype if there is interest.
<br>
</p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0">To give a rough idea, it uses a TableGen mechanism to describe the OpenCL builtin functions (similar to intrinsics in LLVM). During the Clang build phase, a trie file is generated. There is a hook in Clang that uses the
generated trie to lookup the builtin function name during call resolution in Sema. After a successful lookup it generates the AST declaration of a function with overloads and the rest just follows the unmodified Clang flow (i.e. checking overloading, mangling,
etc). This will cover all builtins, not just conversions and maths. It is easy to extend. It doesn't need to change much of Clang code, as it allows to follow normal compilation flow.
<br>
</p>
<br>
<p style="margin-top:0;margin-bottom:0">Do you think it would make sense to evaluate this solution as well?</p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0">Cheers,</p>
<p style="margin-top:0;margin-bottom:0">Anastasia<br>
</p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<br>
<br>
<div style="color: rgb(0, 0, 0);">
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" color="#000000" face="Calibri, sans-serif"><b>From:</b> cfe-dev <cfe-dev-bounces@lists.llvm.org> on behalf of Andrew Savonichev via cfe-dev <cfe-dev@lists.llvm.org><br>
<b>Sent:</b> 25 September 2018 16:02<br>
<b>To:</b> cfe-dev@lists.llvm.org<br>
<b>Subject:</b> [cfe-dev] [RFC][OpenCL] Implement OpenCL builtin functions in Clang</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">Hello,<br>
<br>
OpenCL C language has ~200 builtin functions defined in the<br>
specification: math builtins (sin, cos, tan, etc.), conversion builtins<br>
(float -> half, char2 -> int2), image builtins, and many others.<br>
<br>
Currently, all these builtins are declared in `opencl-c.h' header for<br>
each supported combination of types (using `overloadable' attribute), so<br>
~200 builtins turn into ~14000 function declarations.<br>
<br>
It takes a significant amount of time to parse these ~14000<br>
declarations, and we have to do it for *every* OpenCL C program. This<br>
leads to bad compile time performance for small OpenCL C programs, and<br>
most of the time is eaten by `opencl-c.h' header.<br>
<br>
There were several of attempts to improve this design by pre-compilation<br>
(see D51544: Split opencl-c.h header[1]), but pre-compiled headers are<br>
difficult to manage, and they make overall design more complicated.<br>
<br>
Alternatively, we can implement all these ~200 builtins in clang. With a<br>
custom type checking we can handle different argument types. Custom<br>
codegen can generate mangled function calls, so IR should be identical<br>
to what we had before.<br>
<br>
In the future, I think we can add a switch to replace mangled functions<br>
with LLVM IR intrinsics, as it could be useful for SPIR-V translation<br>
(see SPIR-V discussion[4] for rationale).<br>
<br>
I implemented several builtins as a POC:<br>
<br>
- D52457: [OpenCL] Implement OpenCL convert builtin [2]<br>
- D52458: [OpenCL] Implement OpenCL math builtins: fp -> fp [3]<br>
<br>
Implementation of the remaining ~150 builtins should be straightforward,<br>
but it is time-consuming, so I'd like to make sure that:<br>
<br>
1) this approach fits the needs of OpenCL community<br>
<br>
2) the rest of the Clang community is OK with adding a few hundred<br>
builtins to Clang.<br>
<br>
<br>
[1]: <a href="https://reviews.llvm.org/D51544">https://reviews.llvm.org/D51544</a><br>
[2]: <a href="https://reviews.llvm.org/D52457">https://reviews.llvm.org/D52457</a><br>
[3]: <a href="https://reviews.llvm.org/D52458">https://reviews.llvm.org/D52458</a><br>
[4]: <a href="https://lists.llvm.org/pipermail/llvm-dev/2018-September/125977.html">
https://lists.llvm.org/pipermail/llvm-dev/2018-September/125977.html</a><br>
<br>
-- <br>
Andrew<br>
<br>
--------------------------------------------------------------------<br>
Joint Stock Company Intel A/O<br>
Registered legal address: Krylatsky Hills Business Park,<br>
17 Krylatskaya Str., Bldg 4, Moscow 121614,<br>
Russian Federation<br>
<br>
This e-mail and any attachments may contain confidential material for<br>
the sole use of the intended recipient(s). Any review or distribution<br>
by others is strictly prohibited. If you are not the intended<br>
recipient, please contact the sender and delete all copies.<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
cfe-dev@lists.llvm.org<br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</div>
</span></font></div>
</div>
</div>
</body>
</html>