<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
span.EmailStyle20
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
/* List Definitions */
@list l0
        {mso-list-id:754861596;
        mso-list-template-ids:-1040663040;}
@list l0:level1
        {mso-level-tab-stop:.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level2
        {mso-level-tab-stop:1.0in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level3
        {mso-level-tab-stop:1.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level4
        {mso-level-tab-stop:2.0in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level5
        {mso-level-tab-stop:2.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level6
        {mso-level-tab-stop:3.0in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level7
        {mso-level-tab-stop:3.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level8
        {mso-level-tab-stop:4.0in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level9
        {mso-level-tab-stop:4.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l1
        {mso-list-id:2039431564;
        mso-list-template-ids:-1707306722;}
@list l1:level1
        {mso-level-tab-stop:.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l1:level2
        {mso-level-tab-stop:1.0in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l1:level3
        {mso-level-tab-stop:1.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l1:level4
        {mso-level-tab-stop:2.0in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l1:level5
        {mso-level-tab-stop:2.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l1:level6
        {mso-level-tab-stop:3.0in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l1:level7
        {mso-level-tab-stop:3.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l1:level8
        {mso-level-tab-stop:4.0in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l1:level9
        {mso-level-tab-stop:4.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
ol
        {margin-bottom:0in;}
ul
        {margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">> The AST should reflect that: it should not include a conversion operator that’s meaningless at the source level.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Makes sense.  Thanks.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:Consolas">-- </span>
<span style="font-size:9.0pt;font-family:Consolas"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:8.0pt;font-family:Consolas">Krzysztof Parzyszek 
<a href="mailto:kparzysz@quicinc.com"><span style="color:#0563C1">kparzysz@quicinc.com</span></a>   AI tools development<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Eli Friedman <efriedma@quicinc.com> <br>
<b>Sent:</b> Monday, March 9, 2020 7:51 PM<br>
<b>To:</b> Krzysztof Parzyszek <kparzysz@quicinc.com><br>
<b>Cc:</b> cfe-dev@lists.llvm.org<br>
<b>Subject:</b> RE: [EXT] [cfe-dev] Target-specific AST rewriting (clang)<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">If I’m understanding correctly, in the C AST, the builtin takes an operand of type “vector_bool”, which is represented in memory like a “<128 x i8>”.  But the corresponding LLVM builtin takes a “<128 x i1>”.  So you need to emit a “trunc”
 or something like that to do the conversion.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">From your description, it sounds like you can declare variables of type vector_bool.  (If not, I’m not sure why you’re declaring your intrinsics to have arguments of type vector_bool.)  Given that, the bitcasts seem like a distraction,
 so I’ll pretend they’re not there, and the question is just whether we should emit an AST node to represent the conversion from a “memory” vector_bool to a “register” vector_bool.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I think this is not something we should be exposing in the AST.  There is no type conversion at the source level.  The fact that we have to expand the intrinsic call to a sequence of multiple LLVM instructions is a detail of the LLVM backend,
 not a property of the source language.  The source language is intentionally hiding the fact that a conversion is necessary to invoke the instruction in question. The AST should reflect that: it should not include a conversion operator that’s meaningless at
 the source level.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Note that clang CodeGen does distinguish between “memory” and “register” types for scalar booleans; see CodeGenTypes::ConvertType vs. CodeGenTypes::ConvertTypeForMem .  Maybe that would be more helpful for solving your issue?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">-Eli<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Krzysztof Parzyszek <<a href="mailto:kparzysz@quicinc.com">kparzysz@quicinc.com</a>>
<br>
<b>Sent:</b> Monday, March 9, 2020 4:20 PM<br>
<b>To:</b> Eli Friedman <<a href="mailto:efriedma@quicinc.com">efriedma@quicinc.com</a>><br>
<b>Cc:</b> <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<b>Subject:</b> Re: [EXT] [cfe-dev] Target-specific AST rewriting (clang)<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">Assume for brevity that<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">vector_int = __attribute__((__vector_size__(32 * sizeof(int)))) int<o:p></o:p></span></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">vector_bool = __attribute__((__vector_size__(128 * sizeof(_Bool)))) _Bool<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">Consider this AST.  It contains bitcasts from vector_bool to vector_int and the other way around.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">|     `-ImplicitCastExpr 0x807c212b0 <col:10, col:51> 'HVX_Vector':'vector_int' <BitCast><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">|       `-CallExpr 0x807c21220 <col:10, col:51> 'vector_bool'<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">|         |-ImplicitCastExpr 0x807c21208 <col:10> 'vector_bool (*)(vector_bool, vector_bool)' <BuiltinFnToFnPtr><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">|         | `-DeclRefExpr 0x807c21180 <col:10> '<builtin fn type>' Function 0x807c21000 '__builtin_HEXAGON_V6_pred_and_128B' 'vector_bool (vector_bool, vector_bool)'<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">|         |-ImplicitCastExpr 0x807c21268 <col:45> 'vector_bool' <BitCast><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">|         | `-ImplicitCastExpr 0x807c21250 <col:45> 'HVX_Vector':'vector_int' <LValueToRValue><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">|         |   `-DeclRefExpr 0x807c211a0 <col:45> 'HVX_Vector':'vector_int' lvalue ParmVar 0x807a43d10 'a0' 'HVX_Vector':'vector_int'<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">|         `-ImplicitCastExpr 0x807c21298 <col:49> 'vector_bool' <BitCast><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">|           `-ImplicitCastExpr 0x807c21280 <col:49> 'HVX_Vector':'vector_int' <LValueToRValue><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">|             `-DeclRefExpr 0x807c211c0 <col:49> 'HVX_Vector':'vector_int' lvalue ParmVar 0x807a43d88 'a1' 'HVX_Vector':'vector_int'<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
</div>
<div>
<ol start="1" type="1">
<li class="MsoNormal" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo3">
<span style="font-size:12.0pt">These casts are not no-ops, there are instructions that do it (with corresponding builtins/intrinsics). In the actual hardware, the registers holding vector_int are 1024 bits long, the registers holding vector_bool are 128 bits
 long.<o:p></o:p></span></li><li class="MsoNormal" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo3">
<span style="font-size:12.0pt">The "bool" vectors are not storable directly (i.e. no way to store the 128 bits to memory).  Instead, they have to be "expanded" into vector_int (or contracted from vector_int).  In other words, vector_int is the universal storage
 format for both types.<o:p></o:p></span></li></ol>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">Long story short, in C code we want to make these two types look (more or less) the same (i.e. both are 128 bytes), but in LLVM IR they are different (since 32*i32 is not bitcastable to 128*i1). 
 Now, I want to replace these bitcasts with calls to proper builtins, i.e. transform clang's Expr to another Expr.  Right now we deal with it in CGBuiltin as a part of codegen, but it's not elegant (not composable with other per-builtin handling that may need
 to happen in CGBuiltin).<o:p></o:p></span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">-Krzysztof<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
</div>
</div>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="2" width="98%" align="center">
</div>
<div id="divRplyFwdMsg">
<p class="MsoNormal"><b><span style="color:black">From:</span></b><span style="color:black"> Eli Friedman <<a href="mailto:efriedma@quicinc.com">efriedma@quicinc.com</a>><br>
<b>Sent:</b> Monday, March 9, 2020 4:42 PM<br>
<b>To:</b> Krzysztof Parzyszek <<a href="mailto:kparzysz@quicinc.com">kparzysz@quicinc.com</a>><br>
<b>Cc:</b> <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a> <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>><br>
<b>Subject:</b> RE: [EXT] [cfe-dev] Target-specific AST rewriting (clang)</span> <o:p>
</o:p></p>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">I'm not sure I follow what you mean.  Do you mean that given, for example "float x; __builtin_foo(-x);", you call "llvm.foo(-x)", and given "double x; __builtin_foo((float)-x)", you call "llvm.bar(-x)"?  I don't think there's any precedent
 for that, no; normally that's the sort of optimization you'd handle in instcombine.<br>
<br>
-Eli<br>
<br>
> -----Original Message-----<br>
> From: cfe-dev <<a href="mailto:cfe-dev-bounces@lists.llvm.org">cfe-dev-bounces@lists.llvm.org</a>> On Behalf Of Krzysztof<br>
> Parzyszek via cfe-dev<br>
> Sent: Monday, March 9, 2020 12:57 PM<br>
> To: <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
> Subject: [EXT] [cfe-dev] Target-specific AST rewriting (clang)<br>
> <br>
> Hi,<br>
> <br>
> There are some type casts that should be replaced with intrinsics (this is<br>
> Hexagon-specific). Those only occur in calls to Hexagon builtins, and right now<br>
> this replacement happens as a part of clang's codegen.<br>
> However, this replacement is only triggered by types in the AST and the<br>
> corresponding types in the LLVM IR, and is not dependent on the details<br>
> (semantics) of any particular builtin, so I'd like to make it orthogonal to the<br>
> cgbuiltin code that deals with specific intrinsics. I'd like the replacement to<br>
> transform AST->AST, so the result can be easily composed with any code that<br>
> does AST->LLVM IR.<br>
> <br>
> Is there a precedent for something like this?  I could do this right at the<br>
> beginning of EmitHexagonBuiltinExpr, but I was wondering if there was a better<br>
> way.<br>
> <br>
> --<br>
> Krzysztof Parzyszek  <a href="mailto:kparzysz@quicinc.com">kparzysz@quicinc.com</a>   AI tools development<br>
> <br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>