[prev in list] [next in list] [prev in thread] [next in thread]
List: cfe-dev
Subject: Re: [cfe-dev] [RFC][RISCV] Add intrinsic and/or builtin functions by #pragma
From: Anastasia Stulova via cfe-dev <cfe-dev () lists ! llvm ! org>
Date: 2021-06-23 9:46:06
Message-ID: DB6PR08MB2824A9DF915B2B6D8979EE04F0089 () DB6PR08MB2824 ! eurprd08 ! prod ! outlook ! com
[Download RAW message or body]
> Thanks for your explanation! My first impression is the implementation
> is kind of OpenCL specific since there are lots of OpenCL term are
> used in the implementation including the option name used in tablegen,
> but the mechnich seems could be generalized.
Exactly, the names we used are OpenCL specific but the logic can
apply to C-based languages universally. You might find it easy to decode
if you look at the relevant spec part:
https://www.khronos.org/registry/OpenCL/specs/3.0-unified/html/OpenCL_C.htm=
l#built-in-functions
> Could you explain what the TableGen based header is ? Does it mean
> OpenCLBuiltins.inc? or some other headers?
Yes, this is a hook to Sema that is generated by the TableGen from
OpenCLBuiltins.td description.
So if let's say we wanted to generalize the logic we would rename from
"OpenCLBuiltinStruct" -> "BuiltinStruct". Because this is just a data
structure that describes a function with its overloads.
I imagine the only OpenCL-specific parts are Extensions and "gentype".
The concept of "gentype" is taken from
https://www.khronos.org/registry/OpenCL/specs/3.0-unified/html/OpenCL_C.htm=
l#math-functions
This is just a trick to make TableGen description and data structures much
smaller. I think it can be useful outside of OpenCL but only if there are
overloads with vector types for example.
> I guess we still needed for RISC-V since we don't want to import those
symbols until include riscv_vector.h, but that should not conflict
with the OpenCL built-in approach :)
Indeed. In OpenCL language we don't have a way to activate/load the
builtins so they are always available. This is why we activate the Tablegen
header by a flag.
Cheers,
Anastasia
________________________________
From: Kito Cheng <kito.cheng@gmail.com>
Sent: 23 June 2021 07:21
To: Anastasia Stulova <Anastasia.Stulova@arm.com>
Cc: David Rector <davrecthreads@gmail.com>; Clang Dev <cfe-dev@lists.llvm.o=
rg>; Sven Van Haastregt <Sven.VanHaastregt@arm.com>
Subject: Re: [cfe-dev] [RFC][RISCV] Add intrinsic and/or builtin functions =
by #pragma
Hi Anastasia:
Thanks for your explanation! My first impression is the implementation
is kind of OpenCL specific since there are lots of OpenCL term are
used in the implementation including the option name used in tablegen,
but the mechnich seems could be generalized.
> We have removed the need for the pragmas in the last commits but it is ma=
inly
> because it wasn't useful in OpenCL in a way it was defined in the spec as=
it
> was not similar to a header include. The TableGen based header include is=
very
> fast compared to parsing the large header files so I can certainly recomm=
end
> this route.
Could you explain what the TableGen based header is ? Does it mean
OpenCLBuiltins.inc? or some other headers?
I guess we still needed for RISC-V since we don't want to import those
symbols until include riscv_vector.h, but that should not conflict
with the OpenCL built-in approach :)
Thanks!
On Wed, Jun 23, 2021 at 1:50 AM Anastasia Stulova via cfe-dev
<cfe-dev@lists.llvm.org> wrote:
>
> FYI, in case it helps we have started documentation about the internals o=
f the
> approach https://clang.llvm.org/docs/OpenCLSupport.html#opencl-builtins.
> Although it is still a bit concise. There is not much OpenCL specific in =
the
> approach we have implemented so it should be easily generalizable with so=
me
> renaming and minor refactoring (CC to Sven who might be able to provide m=
ore
> info if needed). You might need to add a few special types if you use any=
that
> we don't have in OpenCL yet. Although we have covered a good variety from=
C99
> already.
>
> We have removed the need for the pragmas in the last commits but it is ma=
inly
> because it wasn't useful in OpenCL in a way it was defined in the spec as=
it
> was not similar to a header include. The TableGen based header include is=
very
> fast compared to parsing the large header files so I can certainly recomm=
end
> this route.
>
> Cheers,
> Anastasia
> ________________________________
> From: cfe-dev <cfe-dev-bounces@lists.llvm.org> on behalf of Kito Cheng vi=
a cfe-dev <cfe-dev@lists.llvm.org>
> Sent: 22 June 2021 03:41
> To: David Rector <davrecthreads@gmail.com>
> Cc: Clang Dev <cfe-dev@lists.llvm.org>
> Subject: Re: [cfe-dev] [RFC][RISCV] Add intrinsic and/or builtin function=
s by #pragma
>
> Hi David:
>
> Thanks for your info, I investigate OpenCL intrinsic last few days,
> and I saw OpenCL already use some #pragama to control the extenison
> on/off.
> So I think the mechnish is pretty simiular, the difference is OpenCL
> apporache need to write a new td file to generate those helper
> functions.
>
> And our apparoch is extending existing builtin declare mechnish: add
> one filed to record the enable contdition.
>
> We consider pre-compiled header before, but seems like pre-compiled
> header are not fit RISC-V scenario - having different -march
> combination which will affect the content of the header, so it seems
> not work for RISC-V intrinsic headers.
>
>
> Thanks :)
>
> On Tue, Jun 15, 2021 at 11:11 PM David Rector via cfe-dev
> <cfe-dev@lists.llvm.org> wrote:
> >
> > IIUC OpenCL faced the same issue, and their solution was pretty clever =
and generalizable; a similar approach could conceivably improve compile spe=
eds still further, while also minimizing memory usage and making pragmas un=
necessary. https://lists.llvm.org/pipermail/cfe-dev/2021-February/067610.h=
tml
> >
> > The basic idea if I recall (Anastasia cc=92d might correct me), is to c=
reate 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/overload=
ed declarations (the particulars handled via Tablegen) and returns that.
> >
> > The effect is to "instantiate" these declarations as needed, as if from=
a template.
> >
> > What also seems nice about this approach is that heavy-duty users can a=
lternatively choose to just #include the large header, or use a pre-compile=
d header, and thereby automatically avoid any costs associated with this la=
st-ditch-lookup solution.
> >
> > On Jun 15, 2021, at 2:59 AM, Kito Cheng via cfe-dev <cfe-dev@lists.llvm=
.org> wrote:
> >
> > Hi :
> >
> >
> > # TL;DR:
> >
> > It's the intrinsic and/or builtin functions related issue again, in
> > this RFC we are trying to use pragma to import intrinsics and declare
> > intrinsic wrappers function to reduce the compilation time.
> >
> > And here is the PoC for this RFC:
> > https://reviews.llvm.org/D103228
> >
> > # Background:
> >
> > RISC-V vector extension has defined 25,386 intrinsic and 2,102
> > overloaded intrinsic functions in riscv_vector.h which increase a lot
> > of compilation time; the header file contains ~60k lines for those
> > overload functions and intrinsic wrapper functions.
> >
> > An empty file with include riscv_vector.h takes 0.395s on release
> > build and 8.067s second on debug build, and this also increases the
> > clang test time.
> >
> > # Proposal:
> >
> > Using Tablegen to generate the table of the intrinsic wrapper
> > functions and then using pragma to declare intrinsic wrapper
> > functions.
> >
> > Syntax:
> > ```c
> > #pragma riscv intrinsic vector
> > ```
> >
> > Then import all builtin functions and intrinsic wrappers into the
> > symbol table, this could save lots of time parsing the prototypes of
> > the intrinsic wrapper function.
> >
> > And this idea of trick is borrowing from AArch64/SVE's implementation o=
n GCC:
> > https://github.com/gcc-mirror/gcc/blob/master/gcc/config/aarch64/arm_sv=
e.h#L40
> >
> >
> > # Experimental Results:
> > ## Size of riscv_vector.h:
> > | size | LoC |
> > ------------------------------
> > Before | 4,434,725 | 69,749 |
> > After | 5,463 | 159 |
> >
> > ## Compilation Speed for Simple File
> >
> > testcase:
> > ```c
> > #include <riscv_vector.h>
> >
> > vint32m1_t test_vadd_vv_vfloat32m1_t(vint32m1_t op1, vint32m1_t op2,
> > size_t vl) {
> > return vadd(op1, op2, vl);
> > }
> > ```
> >
> > Release build:
> > Before: 0m0.417s
> > After: 0m0.090s
> >
> > Debug build:
> > Before: 0m8.016s
> > After: 0m2.295s
> >
> >
> > ## Regression Time
> > LLVM regression on our 48 core server:
> > Release build:
> > Before : Testing Time: 203.81s
> > After : Testing Time: 181.13s
> >
> > Debug build:
> > Before : Testing Time: 675.18s
> > After : Testing Time: 647.20s
> >
> >
> >
> > Any comments or feedback are appreciated!
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev@lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >
> >
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev@lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> _______________________________________________
> cfe-dev mailing list
> cfe-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> _______________________________________________
> cfe-dev mailing list
> cfe-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
[Attachment #3 (text/html)]
<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">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; \
color: rgb(0, 0, 0);"> <font size="2"><span style="font-size:11pt">> Thanks for \
your explanation! My first impression is the implementation<br> > is kind of \
OpenCL specific since there are lots of OpenCL term are<br> > used in the \
implementa</span><span style="font-size: 11pt; font-family: calibri, arial, \
helvetica, sans-serif; color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);">tion \
including the option name used in tablegen,</span></font></div> <div \
style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: \
rgb(0, 0, 0);"> <font size="2"><span style="font-size: 11pt; color: rgb(0, 0, 0); \
background-color: rgba(0, 0, 0, 0);">> but the mechnich seems could be \
generalized.</span></font></div> <div style="font-family: Calibri, Arial, Helvetica, \
sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> <br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; \
color: rgb(0, 0, 0);"> <span style="font-family: calibri, arial, helvetica, \
sans-serif; font-size: 11pt; color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, \
0);">Exactly, the names we used are OpenCL specific but the logic can</span></div> \
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; \
color: rgb(0, 0, 0);"> <span style="font-family: calibri, arial, helvetica, \
sans-serif; font-size: 11pt; color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, \
0);">apply to C-based languages universally. You might find it easy to \
decode</span></div> <div style="font-family: Calibri, Arial, Helvetica, sans-serif; \
font-size: 12pt; color: rgb(0, 0, 0);"> <span style="font-family: calibri, arial, \
helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0); background-color: \
rgba(0, 0, 0, 0);">if you look at the relevant spec part:</span></div> <div \
style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: \
rgb(0, 0, 0);"> <span style="font-family: calibri, arial, helvetica, sans-serif; \
font-size: 11pt; color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);"><br> \
</span></div> <div style="font-family: Calibri, Arial, Helvetica, sans-serif; \
font-size: 12pt; color: rgb(0, 0, 0);"> <a \
href="https://www.khronos.org/registry/OpenCL/specs/3.0-unified/html/OpenCL_C.html#built-in-functions" \
id="LPlnk"><span style="font-family: calibri, arial, helvetica, sans-serif; \
font-size: 11pt; color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, \
0);">https://www.khronos.org/registry/OpenCL/specs/3.0-unified/html/OpenCL_C.html#built-in-functions</span></a></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; \
color: rgb(0, 0, 0);"> <br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; \
color: rgb(0, 0, 0);"> <font size="2"><span style="font-size:11pt">> Could you \
explain what the TableGen based header is ? Does it mean<br> </span></font></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; \
color: rgb(0, 0, 0);"> <font size="2"><span style="font-size: 11pt; font-family: \
calibri, arial, helvetica, sans-serif; color: rgb(0, 0, 0); background-color: rgba(0, \
0, 0, 0);">> OpenCLBuiltins.inc? or some other headers?</span></font><br> </div>
<div class="_Entity _EType_OWALinkPreview _EId_OWALinkPreview _EReadonly_1"></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; \
color: rgb(0, 0, 0);"> <br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; \
color: rgb(0, 0, 0);"> <span style="font-family: calibri, arial, helvetica, \
sans-serif; font-size: 11pt; color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, \
0);">Yes, this is a hook to Sema that is generated by the TableGen from</span></div> \
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; \
color: rgb(0, 0, 0);"> <code class="docutils literal notranslate"><span class="pre" \
style="font-family: calibri, arial, helvetica, sans-serif; font-size: 11pt; color: \
rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);">OpenCLBuiltins.td</span></code> \
description.<br> </div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; \
color: rgb(0, 0, 0);"> <br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; \
color: rgb(0, 0, 0);"> <span style="font-family: calibri, arial, helvetica, \
sans-serif; font-size: 11pt; color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, \
0);">So if let's say we wanted to generalize the logic we would rename \
from</span></div> <div style="font-family: Calibri, Arial, Helvetica, sans-serif; \
font-size: 12pt; color: rgb(0, 0, 0);"> <span style="font-family: calibri, arial, \
helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0); background-color: \
rgba(0, 0, 0, 0);">"OpenCLBuiltinStruct" -> "BuiltinStruct". \
Because this is just a data</span></div> <div style="font-family: Calibri, Arial, \
Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> <span \
style="font-family: calibri, arial, helvetica, sans-serif; font-size: 11pt; color: \
rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);">structure that describes a \
function with its overloads.</span></div> <div style="font-family: Calibri, Arial, \
Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> <br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; \
color: rgb(0, 0, 0);"> <span style="font-family: calibri, arial, helvetica, \
sans-serif; font-size: 11pt; color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, \
0);">I imagine the</span><span style="font-family: calibri, arial, helvetica, \
sans-serif; font-size: 11pt; color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, \
0);"> only OpenCL-specific parts are Extensions and \
"gentype".</span></div> <div style="font-family: Calibri, Arial, Helvetica, \
sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> <span style="font-family: \
calibri, arial, helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0); \
background-color: rgba(0, 0, 0, 0);">The concept of "gentype" is taken \
from</span></div> <div style="font-family: Calibri, Arial, Helvetica, sans-serif; \
font-size: 12pt; color: rgb(0, 0, 0);"> <a \
href="https://www.khronos.org/registry/OpenCL/specs/3.0-unified/html/OpenCL_C.html#math-functions" \
id="LPlnk961764"><span style="font-family: calibri, arial, helvetica, sans-serif; \
font-size: 11pt; color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, \
0);">https://www.khronos.org/registry/OpenCL/specs/3.0-unified/html/OpenCL_C.html#math-functions</span></a></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; \
color: rgb(0, 0, 0);"> <span style="font-family: calibri, arial, helvetica, \
sans-serif; font-size: 11pt; color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, \
0);">This is just a trick to make TableGen description and data structures \
much</span></div> <div style="font-family: Calibri, Arial, Helvetica, sans-serif; \
font-size: 12pt; color: rgb(0, 0, 0);"> <span style="font-family: calibri, arial, \
helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0); background-color: \
rgba(0, 0, 0, 0);">smaller. I think it can be useful outside of OpenCL but only if \
there are</span></div> <div style="font-family: Calibri, Arial, Helvetica, \
sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> <span style="font-family: \
calibri, arial, helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0); \
background-color: rgba(0, 0, 0, 0);">overloads with vector types for \
example.</span></div> <div style="font-family: Calibri, Arial, Helvetica, sans-serif; \
font-size: 12pt; color: rgb(0, 0, 0);"> <br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; \
color: rgb(0, 0, 0);"> > <font size="2"><span style="font-size:11pt">I guess we \
still needed for RISC-V since we don't want to import those<br> symbols until include \
riscv_vector.h, but that should not conflict<br> </span><span style="font-size: 11pt; \
font-family: calibri, arial, helvetica, sans-serif;">with the OpenCL built-in \
approach :)</span></font><br> </div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; \
color: rgb(0, 0, 0);"> <br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; \
color: rgb(0, 0, 0);"> <span style="font-family: calibri, arial, helvetica, \
sans-serif; font-size: 11pt; color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, \
0);">Indeed. In OpenCL language we don't have a way to activate/load the</span></div> \
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; \
color: rgb(0, 0, 0);"> <span style="font-family: calibri, arial, helvetica, \
sans-serif; font-size: 11pt; color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, \
0);">builtins so they are always available. This is why we activate the \
Tablegen</span></div> <div style="font-family: Calibri, Arial, Helvetica, sans-serif; \
font-size: 12pt; color: rgb(0, 0, 0);"> <span style="font-family: calibri, arial, \
helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0); background-color: \
rgba(0, 0, 0, 0);">header by a flag.</span><br> </div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; \
color: rgb(0, 0, 0);"> <br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; \
color: rgb(0, 0, 0);"> <span style="font-family: calibri, arial, helvetica, \
sans-serif; font-size: 11pt; color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, \
0);">Chee</span><span style="font-family: calibri, arial, helvetica, sans-serif; \
font-size: 11pt; color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, \
0);">rs,</span><br> <span style="font-family: calibri, arial, helvetica, sans-serif; \
font-size: 11pt; color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, \
0);">Anastasia</span><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> Kito Cheng \
<kito.cheng@gmail.com><br> <b>Sent:</b> 23 June 2021 07:21<br>
<b>To:</b> Anastasia Stulova <Anastasia.Stulova@arm.com><br>
<b>Cc:</b> David Rector <davrecthreads@gmail.com>; Clang Dev \
<cfe-dev@lists.llvm.org>; Sven Van Haastregt \
<Sven.VanHaastregt@arm.com><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 Anastasia:<br>
<br>
Thanks for your explanation! My first impression is the implementation<br>
is kind of OpenCL specific since there are lots of OpenCL term are<br>
used in the implementation including the option name used in tablegen,<br>
but the mechnich seems could be generalized.<br>
<br>
> We have removed the need for the pragmas in the last commits but it is \
mainly<br> > because it wasn't useful in OpenCL in a way it was defined in the \
spec as it<br> > was not similar to a header include. The TableGen based header \
include is very<br> > fast compared to parsing the large header files so I can \
certainly recommend<br> > this route.<br>
<br>
Could you explain what the TableGen based header is ? Does it mean<br>
OpenCLBuiltins.inc? or some other headers?<br>
<br>
I guess we still needed for RISC-V since we don't want to import those<br>
symbols until include riscv_vector.h, but that should not conflict<br>
with the OpenCL built-in approach :)<br>
<br>
Thanks!<br>
<br>
On Wed, Jun 23, 2021 at 1:50 AM Anastasia Stulova via cfe-dev<br>
<cfe-dev@lists.llvm.org> wrote:<br>
><br>
> FYI, in case it helps we have started documentation about the internals of \
the<br> > approach <a \
href="https://clang.llvm.org/docs/OpenCLSupport.html#opencl-builtins"> \
https://clang.llvm.org/docs/OpenCLSupport.html#opencl-builtins</a>.<br> > Although \
it is still a bit concise. There is not much OpenCL specific in the<br> > approach \
we have implemented so it should be easily generalizable with some<br> > renaming \
and minor refactoring (CC to Sven who might be able to provide more<br> > info if \
needed). You might need to add a few special types if you use any that<br> > we \
don't have in OpenCL yet. Although we have covered a good variety from C99<br> > \
already.<br> ><br>
> We have removed the need for the pragmas in the last commits but it is \
mainly<br> > because it wasn't useful in OpenCL in a way it was defined in the \
spec as it<br> > was not similar to a header include. The TableGen based header \
include is very<br> > fast compared to parsing the large header files so I can \
certainly recommend<br> > this route.<br>
><br>
> Cheers,<br>
> Anastasia<br>
> ________________________________<br>
> From: cfe-dev <cfe-dev-bounces@lists.llvm.org> on behalf of Kito Cheng via \
cfe-dev <cfe-dev@lists.llvm.org><br> > Sent: 22 June 2021 03:41<br>
> To: David Rector <davrecthreads@gmail.com><br>
> Cc: Clang Dev <cfe-dev@lists.llvm.org><br>
> Subject: Re: [cfe-dev] [RFC][RISCV] Add intrinsic and/or builtin functions by \
#pragma<br> ><br>
> 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>
> _______________________________________________<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>
[Attachment #4 (unknown)]
_______________________________________________
cfe-dev mailing list
cfe-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic