<div><div style="background-color:rgba(0,0,0,0)!important;border-color:rgb(0,0,0)!important;color:rgb(0,0,0)!important"><div dir="auto">I understand that, but I think you missed my point. Not all front-ends are clang, and non-C frontends are also interested in this work. And even C might want to eventually want to be able to use these more generally. For example, the current C standard (afaik) doesn’t define what must happen if this pragma tried to use a non-literal constant, such as a template attribute as the arguments. But it’s not obvious to me why LLVM should inherit that limitation. Currently it seems to be implemented in a way that requires special handling in any front-end, influenced strong by the special handling it’s now getting in C. For other languages, it’s doable to expose this to users regardless, but if you’re already considering changing it, my vote would be to use a normal representation with first-class values.</div><div dir="auto"><br></div><div dir="auto">However, I really appreciate the specifics on the concern you brought up, because that’s a good point. <span>If it’s just about better IR printing,</span><span> p</span>erhaps we can just address that directly?</div><div dir="auto"><br></div><div dir="auto" style="background-color:rgba(0,0,0,0)!important;border-color:rgb(0,0,0)!important;color:rgb(0,0,0)!important"><span style="background-color:rgba(0,0,0,0);border-color:rgb(0,0,0)">Most simply, perhaps </span><span style="border-color:rgb(0,0,0)">these calls could customize the printing to append a comment? Some places already do that, for example to show Function Attributes.</span><br></div><div dir="auto"><div dir="auto"><br></div></div><div dir="auto">Similarly, but more major, LLVM could perhaps define a new “named constant” syntax for the parser format (either with special tokens like your current PR and/or that get defined elsewhere like existing global constants). Certain instructions (such as these) could then use the option to customize the printing of their arguments to use the named constant (after parsing, they’d just be a normal Constant—only printing would optionally use them to show the information better to the reader).</div></div></div><div><div style="background-color:rgba(0,0,0,0)!important;border-color:rgb(0,0,0)!important;color:rgb(0,0,0)!important"><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Thu, Nov 14, 2019 at 15:58 Kaylor, Andrew <<a href="mailto:andrew.kaylor@intel.com" target="_blank">andrew.kaylor@intel.com</a>> wrote:<br></div></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal">Let me clarify. These aren’t intended to be exposed to the user. The user code that leads to the generation of these intrinsics will be normal floating point operations combined with either pragmas (such as “STDC FENV_ACCESS ON”) or command
line options (such as the recently introduced “-fp-model=strict”).<u></u><u></u></p>
<p class="MsoNormal" style="line-height:11.95pt;background-color:rgb(248,248,248)">
The reason I’ve been avoiding normal constant values is that it provides no information when you’re reading the IR. For example:<br>
<br>
<b><span style="font-size:10pt;font-family:"Courier New";color:rgb(85,85,85)">%sum = call double @llvm</span></b><span style="font-size:10pt;font-family:"Courier New";color:rgb(102,102,102)">.</span><span style="font-size:10pt;font-family:"Courier New";color:black">experimental</span><span style="font-size:10pt;font-family:"Courier New";color:rgb(102,102,102)">.</span><span style="font-size:10pt;font-family:"Courier New";color:black">constrained</span><span style="font-size:10pt;font-family:"Courier New";color:rgb(102,102,102)">.</span><span style="font-size:10pt;font-family:"Courier New";color:black">fadd(double
%x, double %y, i32 1, i32 2)</span><u></u><u></u></p>
<p class="MsoNormal">What does that mean? You’d need to consult an external reference to have any idea.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">-Andy<u></u><u></u></p></div></div><div lang="EN-US" link="blue" vlink="purple"><div>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><a name="m_1353712032674032466_m_8518748629804604943______replyseparator"></a><b>From:</b> Jameson Nash <<a href="mailto:vtjnash@gmail.com" target="_blank">vtjnash@gmail.com</a>>
<br>
<b>Sent:</b> Thursday, November 14, 2019 12:27 PM<br>
<b>To:</b> Kaylor, Andrew <<a href="mailto:andrew.kaylor@intel.com" target="_blank">andrew.kaylor@intel.com</a>><br>
<b>Cc:</b> LLVM Developers Mailing List <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
<b>Subject:</b> Re: [llvm-dev] RFC: token arguments and operand bundles<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">From a front-end perspective, I think it'd be preferable if these either got encoded in the function name or were normal enum value arguments. It's a bit awkward to expose things to the user that must be constant or of a special type or
in a special metadata slot, since we now need more special support for it. If the optimization passes couldn't identify a constant value for one of the arguments, these seem like they can fallback to assuming the most conservative semantics (of round.dynamic
and fpexcept.strict--e.g. don't optimize) without loss of precision or generality.<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">-Jameson<u></u><u></u></p>
</div>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Thu, Nov 14, 2019 at 2:40 PM Kaylor, Andrew via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-style:none none none solid;border-left-width:1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in;border-left-color:rgb(204,204,204)">
<div>
<div>
<p class="MsoNormal">Hello everyone,<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">I’ve just uploaded a patch (<a href="https://reviews.llvm.org/D70261" target="_blank">https://reviews.llvm.org/D70261</a>) to introduce a could of new token types to be used with
constrained floating point intrinsics and, optionally, vector predicated intrinsics. These intrinsics may not be of interest to many of you, but I have a more general question.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">I would like some general feedback on the way I am proposing to use token arguments and operand bundles. I have an incomplete understanding of how these are intended to be used,
and I want to make sure what I have in mind is consistent with the philosophy behind them.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Currently, the constrained floating point intrinsics require string metadata arguments to describe the rounding mode and exception semantics. These “arguments” are really providing
information to the optimizer about what it can and cannot assume when acting on these intrinsics. The rounding mode argument potentially overrides the default optimizer assumption that the “to nearest” rounding mode is in use, and the exception behavior argument
overrides the default optimizer assumption that floating point operations have no side effects. I’ve never liked the use of strings here, and the fact that these arguments are not actually inputs to the operation represented by the intrinsic seems vaguely
wrong.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">A typical call to a current intrinsic looks like this:<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<div style="border:1pt solid rgb(204,204,204);padding:6pt">
<p class="MsoNormal" style="line-height:11.95pt;background-color:rgb(248,248,248)">
<b><span style="font-size:10pt;font-family:"Courier New";color:rgb(85,85,85)">%sum = call double @llvm</span></b><span style="font-size:10pt;font-family:"Courier New";color:rgb(102,102,102)">.</span><span style="font-size:10pt;font-family:"Courier New";color:black">experimental</span><span style="font-size:10pt;font-family:"Courier New";color:rgb(102,102,102)">.</span><span style="font-size:10pt;font-family:"Courier New";color:black">constrained</span><span style="font-size:10pt;font-family:"Courier New";color:rgb(102,102,102)">.</span><span style="font-size:10pt;font-family:"Courier New";color:black">fadd(double
%x,</span><u></u><u></u></p>
<p class="MsoNormal" style="line-height:11.95pt;background-color:rgb(248,248,248)">
<span style="font-size:10pt;font-family:"Courier New";color:black"> double %y,</span><u></u><u></u></p>
<p class="MsoNormal" style="line-height:11.95pt;background-color:rgb(248,248,248)">
<span style="font-size:10pt;font-family:"Courier New";color:black"> Metadata “fpround.dynamic”,</span><u></u><u></u></p>
<p class="MsoNormal" style="line-height:11.95pt;background-color:rgb(248,248,248)">
<span style="font-size:10pt;font-family:"Courier New";color:black"> Metadata “fpexcept.strict”)</span><u></u><u></u></p>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">The idea I am pursuing in my patch is to replace these metadata arguments with optional operand bundles, “fpround” and “fpexcept”. If the operand bundles are present, they would
mean what the arguments currently mean. If not, the default assumption is allowed. A typical call to a constrained intrinsic would look like this:<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<div style="border:1pt solid rgb(204,204,204);padding:6pt">
<p class="MsoNormal" style="line-height:11.95pt;background-color:rgb(248,248,248)">
<b><span style="font-size:10pt;font-family:"Courier New";color:rgb(85,85,85)">%sum = call double @llvm</span></b><span style="font-size:10pt;font-family:"Courier New";color:rgb(102,102,102)">.</span><span style="font-size:10pt;font-family:"Courier New";color:black">experimental2</span><span style="font-size:10pt;font-family:"Courier New";color:rgb(102,102,102)">.</span><span style="font-size:10pt;font-family:"Courier New";color:black">constrained</span><span style="font-size:10pt;font-family:"Courier New";color:rgb(102,102,102)">.</span><span style="font-size:10pt;font-family:"Courier New";color:black">fadd(double
%x,</span><u></u><u></u></p>
<p class="MsoNormal" style="line-height:11.95pt;background-color:rgb(248,248,248)">
<span style="font-size:10pt;font-family:"Courier New";color:black"> double %y) [ “fpround”(token rmDynamic),</span><u></u><u></u></p>
<p class="MsoNormal" style="line-height:11.95pt;background-color:rgb(248,248,248)">
<span style="font-size:10pt;font-family:"Courier New";color:black"> “fpexcept”(token ebStrict) ]</span><u></u><u></u></p>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Does that seem like a valid use of tokens and operand bundles? Does it seem better than the current approach?<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Thanks,<u></u><u></u></p>
<p class="MsoNormal">Andy<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><u></u><u></u></p>
</blockquote>
</div>
</div>
</div>
</blockquote></div></div>
</div>