<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
FYI, in case it helps we have started documentation about the internals of the
<div>approach https://clang.llvm.org/docs/OpenCLSupport.html#opencl-builtins. </div>
<div>Although it is still a bit concise. There is not much OpenCL specific in the
</div>
<div>approach we have implemented so it should be easily generalizable with some </div>
<div>renaming and minor refactoring (CC to Sven who might be able to provide more
</div>
<div>info if needed). You might need to add a few special types if you use any that
</div>
<div>we don't have in OpenCL yet. Although we have covered a good variety from C99
</div>
<div>already. </div>
<div><br>
</div>
<div>We have removed the need for the pragmas in the last commits but it is mainly
</div>
<div>because it wasn't useful in OpenCL in a way it was defined in the spec as it
</div>
<div>was not similar to a header include. The TableGen based header include is very
</div>
<div>fast compared to parsing the large header files so I can certainly recommend
</div>
<div>this route.</div>
<div><br>
</div>
<div>Cheers,<br>
Anastasia<br>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> cfe-dev <cfe-dev-bounces@lists.llvm.org> on behalf of Kito Cheng via cfe-dev <cfe-dev@lists.llvm.org><br>
<b>Sent:</b> 22 June 2021 03:41<br>
<b>To:</b> David Rector <davrecthreads@gmail.com><br>
<b>Cc:</b> Clang Dev <cfe-dev@lists.llvm.org><br>
<b>Subject:</b> Re: [cfe-dev] [RFC][RISCV] Add intrinsic and/or builtin functions by #pragma</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">Hi David:<br>
<br>
Thanks for your info, I investigate OpenCL intrinsic last few days,<br>
and I saw OpenCL already use some #pragama to control the extenison<br>
on/off.<br>
So I think the mechnish is pretty simiular, the difference is OpenCL<br>
apporache need to write a new td file to generate those helper<br>
functions.<br>
<br>
And our apparoch is extending existing builtin declare mechnish: add<br>
one filed to record the enable contdition.<br>
<br>
We consider pre-compiled header before, but seems like pre-compiled<br>
header are not fit RISC-V scenario - having different -march<br>
combination which will affect the content of the header, so it seems<br>
not work for RISC-V intrinsic headers.<br>
<br>
<br>
Thanks :)<br>
<br>
On Tue, Jun 15, 2021 at 11:11 PM David Rector via cfe-dev<br>
<cfe-dev@lists.llvm.org> wrote:<br>
><br>
> IIUC OpenCL faced the same issue, and their solution was pretty clever and generalizable; a similar approach could conceivably improve compile speeds still further, while also minimizing memory usage and making pragmas unnecessary.
<a href="https://lists.llvm.org/pipermail/cfe-dev/2021-February/067610.html">https://lists.llvm.org/pipermail/cfe-dev/2021-February/067610.html</a><br>
><br>
> The basic idea if I recall (Anastasia cc’d might correct me), is to create the necessarily declarations whenever lookup fails. I.e., if lookup of `vint32m1_t` fails, before giving up clang checks if that is the name of one of your intrinsics; if so it adds
the necessarily declaration/overloaded declarations (the particulars handled via Tablegen) and returns that.<br>
><br>
> The effect is to "instantiate" these declarations as needed, as if from a template.<br>
><br>
> What also seems nice about this approach is that heavy-duty users can alternatively choose to just #include the large header, or use a pre-compiled header, and thereby automatically avoid any costs associated with this last-ditch-lookup solution.<br>
><br>
> On Jun 15, 2021, at 2:59 AM, Kito Cheng via cfe-dev <cfe-dev@lists.llvm.org> wrote:<br>
><br>
> Hi :<br>
><br>
><br>
> # TL;DR:<br>
><br>
> It's the intrinsic and/or builtin functions related issue again, in<br>
> this RFC we are trying to use pragma to import intrinsics and declare<br>
> intrinsic wrappers function to reduce the compilation time.<br>
><br>
> And here is the PoC for this RFC:<br>
> <a href="https://reviews.llvm.org/D103228">https://reviews.llvm.org/D103228</a><br>
><br>
> # Background:<br>
><br>
> RISC-V vector extension has defined 25,386 intrinsic and 2,102<br>
> overloaded intrinsic functions in riscv_vector.h which increase a lot<br>
> of compilation time; the header file contains ~60k lines for those<br>
> overload functions and intrinsic wrapper functions.<br>
><br>
> An empty file with include riscv_vector.h takes 0.395s on release<br>
> build and 8.067s second on debug build, and this also increases the<br>
> clang test time.<br>
><br>
> # Proposal:<br>
><br>
> Using Tablegen to generate the table of the intrinsic wrapper<br>
> functions and then using pragma to declare intrinsic wrapper<br>
> functions.<br>
><br>
> Syntax:<br>
> ```c<br>
> #pragma riscv intrinsic vector<br>
> ```<br>
><br>
> Then import all builtin functions and intrinsic wrappers into the<br>
> symbol table, this could save lots of time parsing the prototypes of<br>
> the intrinsic wrapper function.<br>
><br>
> And this idea of trick is borrowing from AArch64/SVE's implementation on GCC:<br>
> <a href="https://github.com/gcc-mirror/gcc/blob/master/gcc/config/aarch64/arm_sve.h#L40">
https://github.com/gcc-mirror/gcc/blob/master/gcc/config/aarch64/arm_sve.h#L40</a><br>
><br>
><br>
> # Experimental Results:<br>
> ## Size of riscv_vector.h:<br>
> | size | LoC |<br>
> ------------------------------<br>
> Before | 4,434,725 | 69,749 |<br>
> After | 5,463 | 159 |<br>
><br>
> ## Compilation Speed for Simple File<br>
><br>
> testcase:<br>
> ```c<br>
> #include <riscv_vector.h><br>
><br>
> vint32m1_t test_vadd_vv_vfloat32m1_t(vint32m1_t op1, vint32m1_t op2,<br>
> size_t vl) {<br>
> return vadd(op1, op2, vl);<br>
> }<br>
> ```<br>
><br>
> Release build:<br>
> Before: 0m0.417s<br>
> After: 0m0.090s<br>
><br>
> Debug build:<br>
> Before: 0m8.016s<br>
> After: 0m2.295s<br>
><br>
><br>
> ## Regression Time<br>
> LLVM regression on our 48 core server:<br>
> Release build:<br>
> Before : Testing Time: 203.81s<br>
> After : Testing Time: 181.13s<br>
><br>
> Debug build:<br>
> Before : Testing Time: 675.18s<br>
> After : Testing Time: 647.20s<br>
><br>
><br>
><br>
> Any comments or feedback are appreciated!<br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> cfe-dev@lists.llvm.org<br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
><br>
><br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> cfe-dev@lists.llvm.org<br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
_______________________________________________<br>
cfe-dev mailing list<br>
cfe-dev@lists.llvm.org<br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</div>
</span></font></div>
</body>
</html>