<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=utf-8">
<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:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
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.gmail-im
{mso-style-name:gmail-im;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@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="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Hi Jameson,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I don’t think I have a clear picture of what you want to be able to do from the front end. I’ll take a stab at it here, but maybe you could give me an example if what I’m saying is off base.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Modifying my earlier IR example with the assumption that we’d provide intrinsics for changing the rounding mode and use live values for the constraint operands, I’m imagining that you’re asking to be able to do something like this:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">define double @foo(double %A, double %B, double %C) {<o:p></o:p></p>
<p class="MsoNormal"> %orig.rm = call i32 @llvm.getround()<o:p></o:p></p>
<p class="MsoNormal"> %new.rm = call i32 @llvm.setround(i32 2) ; 2=rmTowardZero (unlike C’s fesetround() llvm.setround returns the new rounding mode)<o:p></o:p></p>
<p class="MsoNormal"> %tmp = call double @llvm.experimental.constrained.fadd(double %A, double %B, i32 %new.rm, i32 2) ; %new.rm = dynamically known, 2=strict<o:p></o:p></p>
<p class="MsoNormal"> %restored.rm = call i32 @fesetround(i32 %orig.rm)<o:p></o:p></p>
<p class="MsoNormal"> %result = call double @llvm.experimental.constrained.fadd(double %tmp, double %C, i32 %restored.rm, i32 2) ; %restored.rm = dynamically known, 2 = strict<o:p></o:p></p>
<p class="MsoNormal"> ret double %result<o:p></o:p></p>
<p class="MsoNormal">}<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">If we had a way to get here, the constant folder could easily be taught to do what I suggested with regard to deducing the rounding mode from calls that set it. However, I think it would be an extremely onerous task for a front end to create
the IR above. So, I think I must be wrong about this being what you want to do.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Regarding the IEEE 754, I have a hard time mapping its language to a front end implementation sometimes. I think it intends to leave implementation details completely up to the implementation. I frequently flip back and forth between the
IEEE 754 spec and the C99 fenv spec trying to make sense of it. I believe that when section for of the IEEE spec talks about attributes that maps (mostly) to what the C99 spec calls the “floating point environment” (and we’ve adopted that terminology in the
LLVM Language Reference). I would argue that what IEEE 754 refers to as the “dynamic mode variable” is either amorphous or target defined. For X86 targets, for instance, the MXCSR and FPCW/FPSW registers represent this “variable” at runtime. Are you suggesting
that you’d like it to be an actual value represented in the module somewhere? I can see how that might be useful for a front end, but I don’t know how we’d handle it during machine code generation.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Basically, I think I need more context to understand your concerns.<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"><a name="_____replyseparator"></a><b>From:</b> Jameson Nash <vtjnash@gmail.com>
<br>
<b>Sent:</b> Friday, November 15, 2019 1:58 PM<br>
<b>To:</b> Kaylor, Andrew <andrew.kaylor@intel.com><br>
<b>Cc:</b> LLVM Developers Mailing List <llvm-dev@lists.llvm.org><br>
<b>Subject:</b> Re: [llvm-dev] RFC: token arguments and operand bundles<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">Hi Simon! Yep, I too much appreciate that you asked for discussion. I'm hope I'm not giving you more than you bargained for! (I likely wouldn't have seen this otherwise until the next LLVM release)<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Yep, I think we're on the same page about the expectations of these operands. I'm aware that the user and/or front-end needs to also explicitly set the state.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Yes, we use IRBuilder. But that's not problem. The problem is that it assumes that all front-ends want to maintain this information as global lexical state until llvm lowering. That's OK for clang, since it doesn't currently do optimizations
on an intermediate IR. But I'm arguing that it'd be easier for other front-ends to pick up this work too if LLVM uses the regular call-argument channel for this information. Currently, it seems it expects that all front-ends will do some sort of legalization
and move this information into some sort of a side-channel (as we know that C99 currently specifies). That's doable, it'd just be nicer if that was buried inside the llvm optimization passes that already know about it.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">> As such there is little value in allowing variable exception/rounding mode params for the contrained fp intrinsics - LLVM passes wouldn't understand them (in all but trivial cases) and would have to assume the worst case (dynamic/strict)
anyway.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">We may have to agree to disagree here, but this is exactly what I'm asking for LLVM to do. I don't want LLVM to complicate life just because all optimizations might not be applicable sometimes. There's lots of optimizations that might not
be applicable, and I want to avoid coding in the exceptions in my frontend if I don't need to.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I'm not familiar enough with IEEE 754 to know if it specifies behaviors for the representation in the middle-end. I thought it talked more about allowable optimizations and required features than specific representation questions. Cherry-picking
text, perhaps the closest to my argument would be the sentence in 4.2 that the "user can specify that the attribute parameter [from a] variable." It's not really saying that you have to be able to pass this in as a variable, but I'm going to pretend that I
can make that claim anyways, haha.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">> uses the information it finds there to change the rounding mode operand in the first fadd to rmTowardZero<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">That sounds neat. I don't think it should conflict with passing in the mode as a variable though. Since the langref says the value must agree with the current mode, I think it'd still be legal optimization to replace the argument value
with a more precise one (either Value->Constant, or dynamic->known, or perhaps even replace it with undef if it sees that the mode must be wrong). If you don't think that's legal though, that would lend credibility to the need to use a custom token representation
in an operand-bundle.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Also, I thought Simon seemed to be saying this analysis pass wouldn't be legal ("there is no going back from dynamic fpexcept/fpround to constants"), but I think I must have misunderstood him, since I don't think that's what he meant.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">> To me it seems constant tokens do the job just fine without the need for a custom code path.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">I guess I would have called custom tokens a custom code path too. I don't think it's a question about whether we need represent this custom information—we clearly do—just at which places in the pipelines and representations should there
be customizations to hold the information.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Best,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Jameson<o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Fri, Nov 15, 2019 at 3:17 PM Kaylor, Andrew <<a href="mailto:andrew.kaylor@intel.com">andrew.kaylor@intel.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">We really have been trying to keep in mind that LLVM needs to support multiple front ends, which may be implementing different language standards. As much as possible, I’ve been
trying to let the IEEE 754 spec drive my thinking about this, though I’ll admit that on a few points I’ve use the C99 spec as a sort of reference interpretation of IEEE 754.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">LLVM’s IRBuilder has been recently updated to provide an abstraction layer between front ends and the optimizer. So, if you’re using IRBuilder, you set need to call setIsFPConstrained()
then, optionally, IRBuilder::setDefaultConstraiedExcept() and/or setDefaultConstrainedRounding(). After that, calls to something like IRBuilder::CreateFAdd() will automatically create the constrained intrinsic with the appropriate constraints, regardless of
how we end up representing them. If your front end isn’t using IRBuilder, I will admit it gets a bit more complicated.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I wouldn’t be opposed to a solution that involved a custom printer for these arguments, but I don’t think it really adds anything that we wouldn’t get from using tokens as I have
proposed. Likewise with the named constant idea. On the other hand, if I’m misusing tokens then maybe what constants would add is a way to avoid that misuse.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Regarding the question of what is exposed to users and how, that’s mostly up to the front end. I would like to clarify how we intend for this to work, in general. Simon touched
on this briefly, but I’d like to be a bit more verbose to make sure we’re all on the same page.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">There are effectively two distinct modes of source code translation to IR with respect to floating point operations -- one where the user is allowed to modify the floating point
environment and one where they are not. This may not have been clear to everyone, but by default LLVM IR carries with it the assumption that the runtime rounding mode is “to nearest” and that floating point operations do not have side effects. This was only
documented recently, but this is the way the optimizer has always behaved. In this default mode, the IR *shouldn’t* change the floating point environment. I would encourage front ends to document this more specifically saying that the user is not permitted
to change the FP environment.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">This leads to the necessity of a second state in which the optimizer does not assume the default rounding mode and does not assume that floating point operations have no side effects.
Proscribing these assumptions limits optimization, so we want to continue allowing the assumptions by default. The state where the assumptions are not made is accomplished through the use of constrained intrinsics. However, we do not wish to completely eliminate
optimizations in all cases, so we want a way to communicate to the optimizer what it can assume. That is the purpose of the fpround and fpexcept arguments. These are not intended to control the rounding mode or exception reporting. They only tell the compiler
what it can assume.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Understanding this, front ends can control these in any way they see fit. For instance, the front end might have a global setting the changes the rounding mode to “toward zero.”
In that case, it would create constrained intrinsics for all FP operations and set the rounding mode argument (however we end up representing in) to rmTowardZero (a constant currently defined by LLVM corresponding to the “fpround.towardzero” metadata argument).
Then the optimizer can use this information to perform optimizations like constant folding.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Runtime changes to the rounding mode are a separate matter. As I said above, I think front ends should define clear circumstances under which such changes are permitted, but the
mechanism for making such changes is independent of the constrained FP intrinsics. For example, consider the following C function.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">double foo(double A, double B, double C) {<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> int OrigRM = fegetround();<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> fesetround(FE_TOWARDZERO);<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> double tmp = A + B;<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> fesetround(OrigRM);<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> return tmp + C;<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">}<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Assuming the compiler was in a state where it knew fenv access was enabled, I would expect that to get translated to something like this (after SROA cleanup):<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">define double @foo(double %A, double %B, double %C) {<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> %orig.rm = call i32 @fegetround()<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> %ignored = call i32 @fesetround(i32 3072)<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> %tmp = call double @llvm.experimental.constrained.fadd(double %A, double %B) [ “fpround”(token rmDynamic), “fpexcept”(token rmStrict) ]<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> %ignored = call i32 @fesetround(i32 %orig.rm)<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> %result = call double @llvm.experimental.constrained.fadd(double %tmp, double %C) [ “fpround”(token rmDynamic), “fpexcept”(token rmStrict) ]<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">}<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Notice here the literal constant that C defines is still used for the call to fesetround(FE_TOWARDZERO), and the variable is used for the call that restores the rounding mode. Also
notice that in both fadd operations, the rounding mode is declared as rmDynamic. I have an idea that we ought to have a pass that recognizes the fesetround library call an uses the information it finds there to change the rounding mode operand in the first
fadd to rmTowardZero, but the front end won’t be expected to do that. We’ll probably want an intrinsic to change the rounding mode so that we don’t need to recognize all manner of language-specific libcalls, but that’s a problem for later.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I hope this has been more helpful than tedious. Also, I feel like I should reiterate that I am still seeking all opinions about the use of tokens and operand bundles or any other
means of representing the fp constraints. I just want to make sure that we all have the same understanding of what the information I’m trying to represent in IR means.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">-Andy
<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><a name="m_9219343720693476265______replyseparato"></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 8:00 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<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt: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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">However, I really appreciate the specifics on the concern you brought up, because that’s a good point. If it’s just about better IR printing, perhaps we can just address that directly?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="border:none windowtext 1.0pt;padding:0in">Most simply, perhaps these calls could customize the printing to append a comment? Some places already do that, for example
to show Function Attributes.</span><o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt: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).<o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt: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:<o:p></o:p></p>
</div>
</div>
<div>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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”).<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;line-height:11.95pt;background:#F8F8F8">
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: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, double %y, i32 1, i32 2)</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">What does that mean? You’d need to consult an external reference to have any idea.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">-Andy<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><a name="m_9219343720693476265_m_1353712032674032"></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<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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.<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">-Jameson<o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Hello everyone,<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">A typical call to a current intrinsic looks like this:<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <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="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;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,</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;line-height:11.95pt;background:#F8F8F8">
<span style="font-size:10.0pt;font-family:"Courier New";color:black"> double %y,</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;line-height:11.95pt;background:#F8F8F8">
<span style="font-size:10.0pt;font-family:"Courier New";color:black"> Metadata “fpround.dynamic”,</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;line-height:11.95pt;background:#F8F8F8">
<span style="font-size:10.0pt;font-family:"Courier New";color:black"> Metadata “fpexcept.strict”)</span><o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <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="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;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,</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;line-height:11.95pt;background:#F8F8F8">
<span style="font-size:10.0pt;font-family:"Courier New";color:black"> double %y) [ “fpround”(token rmDynamic),</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;line-height:11.95pt;background:#F8F8F8">
<span style="font-size:10.0pt;font-family:"Courier New";color:black"> “fpexcept”(token ebStrict) ]</span><o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Thanks,<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Andy<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">_______________________________________________<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><o:p></o:p></p>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</body>
</html>