<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)">
<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;}
/* 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:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:"Courier New";}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.nd
{mso-style-name:nd;}
span.o
{mso-style-name:o;}
span.n
{mso-style-name:n;}
span.p
{mso-style-name:p;}
span.nb
{mso-style-name:nb;}
span.EmailStyle26
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle28
{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;}
--></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="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal">Hi Joseph,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks for the feedback. Ulrich Weigand raised the same concern about tokens in my Phabricator review. As I said there, I see the point. I’m definitely proposing a new use for the token type. For my use to be valid, I’d need to redefine
token something like this: “a compiler-generated pseudo-value that is not intended to be represented in memory or register during program execution and can only be used by compiler-specific intrinsics and instructions.” I think that covers the existing uses
correctly. It is a new definition, but not one that would require any changes to implement.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The other characteristics of tokens, such as not being allowed in PHI or select instructions, are exactly what I’m after. I want a type of value that means what the optimizer says it means and nothing else. However, I will admit that what
I want is more like an immediate operand that can only have one of the small set of existing values. Unlike the tokens used by Windows exception handling and coroutine intrinsics, I don’t want these values to be part of a use-def chain, though perhaps Jameson
does want that.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Anyway, I agree with your assessment that the operand bundle part of my proposal is on more solid ground than the token part.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
<p class="MsoNormal">Andy<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><a name="_____replyseparator"></a><b>From:</b> Joseph Tremoulet <jotrem@microsoft.com>
<br>
<b>Sent:</b> Friday, November 15, 2019 1:07 PM<br>
<b>To:</b> Kaylor, Andrew <andrew.kaylor@intel.com><br>
<b>Cc:</b> llvm-dev <llvm-dev@lists.llvm.org><br>
<b>Subject:</b> RE: RFC: token arguments and operand bundles<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">As I recall, tokens were added largely as a mechanism to constrain particular users to particular single-entry regions of the CFG, and to do so in a way that guaranteed that later phases would be able to determine to which region any given
use was tied. That sounds pretty different to me than the use here of wanting something that’s less string-y than metadata but prints as something less obtuse than an integer constant. I think it would functionally work to do what you’re proposing, but it
strikes me as mixing unrelated concepts (one of which is already fairly esoteric) in a way that I for one would caution against. Your issue here strikes me as similar to what ‘immArg’ addresses, and I’d imagine that having a way to constrain particular ‘immArg’
arguments to particular known enumerations of values in a way that prints legibly is something that could have other uses as well and involve less conceptual gymnastics. I’ll also note that with the CFG-centric view of tokens, it makes sense that the only
constant token is ‘None’ – you only need one way to indicate “not tied to any region”.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Bundles strike me as a better fit. What strikes me as a bit odd there is that bundles tend (or at least originally tended) to be used to communicate things orthogonal to the semantics of the call itself (or the operation represented by
the call) – the ambient state of the virtual machine, the GC values that happen to be live across the call, the EH region that happens to contain the call. In this new case, the bundle is communicating something relevant to the semantics of the operation
that the call represents… but it’s also true that, like the other examples, it’s communicating something about the context or ambient state at the point of the call, and that it (IIUC) would be applied consistently across the different fp operations… so that
one passes my sniff test, for whatever that’s worth.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I’m also wondering if “named metadata” could help with the readability issue.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">-Joseph<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org">llvm-dev-bounces@lists.llvm.org</a>>
<b>On Behalf Of </b>Kaylor, Andrew via llvm-dev<br>
<b>Sent:</b> Thursday, November 14, 2019 2:40 PM<br>
<b>To:</b> LLVM Developers Mailing List <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>><br>
<b>Subject:</b> [llvm-dev] RFC: token arguments and operand bundles<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Hello everyone,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I’ve just uploaded a patch (<a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Freviews.llvm.org%2FD70261&data=02%7C01%7Cjotrem%40microsoft.com%7C681ef688e2804e28dbf308d7693a70f6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637093572046751978&sdata=BB2AZOZrm2BhlMQg20f88CYkXLTMdwxwP1I9NO3lLZw%3D&reserved=0">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">A typical call to a current intrinsic looks like this:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:solid #CCCCCC 1.0pt;padding:6.0pt 6.0pt 6.0pt 6.0pt">
<p class="MsoNormal" style="line-height:11.95pt;background:#F8F8F8"><b><span style="font-size:10.0pt;font-family:"Courier New";color:#555555">%sum = call double @llvm</span></b><span style="font-size:10.0pt;font-family:"Courier New";color:#666666">.</span><span style="font-size:10.0pt;font-family:"Courier New";color:black">experimental</span><span style="font-size:10.0pt;font-family:"Courier New";color:#666666">.</span><span style="font-size:10.0pt;font-family:"Courier New";color:black">constrained</span><span style="font-size:10.0pt;font-family:"Courier New";color:#666666">.</span><span style="font-size:10.0pt;font-family:"Courier New";color:black">fadd(double
%x,<o:p></o:p></span></p>
<p class="MsoNormal" style="line-height:11.95pt;background:#F8F8F8"><span style="font-size:10.0pt;font-family:"Courier New";color:black"> double %y,<o:p></o:p></span></p>
<p class="MsoNormal" style="line-height:11.95pt;background:#F8F8F8"><span style="font-size:10.0pt;font-family:"Courier New";color:black"> Metadata “fpround.dynamic”,<o:p></o:p></span></p>
<p class="MsoNormal" style="line-height:11.95pt;background:#F8F8F8"><span style="font-size:10.0pt;font-family:"Courier New";color:black"> Metadata “fpexcept.strict”)<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><o:p> </o:p></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:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:solid #CCCCCC 1.0pt;padding:6.0pt 6.0pt 6.0pt 6.0pt">
<p class="MsoNormal" style="line-height:11.95pt;background:#F8F8F8"><b><span style="font-size:10.0pt;font-family:"Courier New";color:#555555">%sum = call double @llvm</span></b><span style="font-size:10.0pt;font-family:"Courier New";color:#666666">.</span><span style="font-size:10.0pt;font-family:"Courier New";color:black">experimental2</span><span style="font-size:10.0pt;font-family:"Courier New";color:#666666">.</span><span style="font-size:10.0pt;font-family:"Courier New";color:black">constrained</span><span style="font-size:10.0pt;font-family:"Courier New";color:#666666">.</span><span style="font-size:10.0pt;font-family:"Courier New";color:black">fadd(double
%x,<o:p></o:p></span></p>
<p class="MsoNormal" style="line-height:11.95pt;background:#F8F8F8"><span style="font-size:10.0pt;font-family:"Courier New";color:black"> double %y) [ “fpround”(token rmDynamic),<o:p></o:p></span></p>
<p class="MsoNormal" style="line-height:11.95pt;background:#F8F8F8"><span style="font-size:10.0pt;font-family:"Courier New";color:black"> “fpexcept”(token ebStrict) ]<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Does that seem like a valid use of tokens and operand bundles? Does it seem better than the current approach?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
<p class="MsoNormal">Andy<o:p></o:p></p>
</div>
</body>
</html>