<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)">
<!--[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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",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
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.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="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">I think you have described the backend issues very well.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">You are correct that Intel architecture machines behave roughly as you describe. There are some wrinkles in that status and control bits are kept in the same
register and there are two such registers, one for MMX/SSE/AVX instructions and one for X87 instructions. But that is all a matter of details, conceptually it is just as you have described.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">It is my understanding that some LLVM backends are already modeling the FP control and status registers. The X86 backend does not. I attempted to add it last
year, but I ran into some complications and backed it out. I think I know how to fix those problems now.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Everyone I’ve talked to up until now is happy to live with performance degradations when using non-default FP modes. The sticking point is that we’d really like
to avoid doing anything that would restrict performance in the default case, which we expect to be used in the vast majority of programs. I’m not sure how much impact restricting FP scheduling in the backend would have. My intuition is that it wouldn’t be
particularly significant, but it would certainly be something worth measuring.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">You’re correct that we currently have no means of communicating the rounding mode and exception behavior to the back end. I’m reluctant to rely on Selection DAG
pattern matching for the STRICT nodes because the existing pattern matching has a large number of variations. If we can re-use those patterns, I definitely want to. That’s the reason that the current implementation was written the way it was.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">To answer your other question, I am not going to be attending the LLVM developers meeting in Bristol. I would, however, be happy to have some sort of virtual
meeting to discuss this with anyone who is interested.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Andy<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></a></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Ulrich Weigand [mailto:Ulrich.Weigand@de.ibm.com]
<br>
<b>Sent:</b> Friday, February 09, 2018 6:42 AM<br>
<b>To:</b> Kaylor, Andrew <andrew.kaylor@intel.com><br>
<b>Cc:</b> bob.huemmer@sas.com; bumblebritches57@gmail.com; cfe-dev@lists.llvm.org; Hal Finkel <hfinkel@anl.gov>; kpn@neutralgood.org; llvm-dev <llvm-dev@lists.llvm.org>; Richard Smith <richard@metafoo.co.uk><br>
<b>Subject:</b> RE: [cfe-dev] Why is #pragma STDC FENV_ACCESS not supported?<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p><span style="font-size:10.0pt">Hi Andrew,</span><br>
<br>
<span style="font-size:10.0pt">sorry for the delay, I only now got some time to look into this a bit more. But I still have a number of questions of how to actually implement this in the back end. Looking at this bottom-up, starting with the behavior of the
actual machine instructions, we have (at least on SystemZ) the following things to consider:</span><br>
<br>
<span style="font-size:10.0pt">A) Rounding mode</span><br>
<br>
<span style="font-size:10.0pt">Most FP arithmetic instructions use the "current rounding mode" as indicated in the floating-point control register. This is currently assumed to never change. To fix this, we need to avoid scheduling FP arithmetic instructions
across instructions that modify the rounding mode. This may also imply avoiding scheduling instructions across function calls, since those may also modify the rounding mode. This can probably be done by modeling the floating-point control register as LLVM
register (or maybe model just the rounding mode bits as its own "register"), have all FP arithmetic instructions in question take this new register as implicit input, and have the register by clobbered by the instructions that change the rounding mode (and
also function calls).</span><br>
<br>
<span style="font-size:10.0pt">B) Floating-point status flags</span><br>
<br>
<span style="font-size:10.0pt">FP instructions set a flag bit in the floating-point status register whenever an IEEE exception condition is recognized. If these flag bits are later tested by application code, we should ensure their value is unchanged by compiler
optimization. Naively modeling the status register is probably overkill here: since every FP instruction would need to be considered to modify (i.e. use and def) that register, this simply has the effect of creating a dependency chain across *all* FP instructions
and makes any kind of instruction scheduling impossible. But this isn't really necessary since the flag bits actually simply accumulate. So it would suffice to have special dependencies from each FP instruction separately directly to the next instruction (or
routine) that reads the status flags. However, I don't really see any easy way to model this type of dependency in the back-end (in particular on the MI level).</span><br>
<br>
<span style="font-size:10.0pt">C) Floating-point exceptions</span><br>
<br>
<span style="font-size:10.0pt">If a mask bit in the floating-point status register is set, then all FP instructions will *trap* whenever an IEEE exception condition is recognized. This means that we need to treat those instructions as having unmodelled side
effects, so that they cannot be speculatively executed. Also, we cannot schedule FP instructions across instructions that set (those bits in) the FP status register -- but the latter is probably automatically done as long as those latter instructions are described
as having unmodeled side effects. Note that this will in effect again create a dependency chain across all FP instructions, so that B) should be implicitly covered as well here.</span><br>
<br>
<span style="font-size:10.0pt">Did I miss anything here? I'm assuming that the behavior on FP instructions on Intel (and other architectures) will be roughly similar, given that this behavior is mostly defined by the IEEE standard.</span><br>
<br>
<br>
<span style="font-size:10.0pt">Now the question in my mind is, how this this all map onto the experimental constrained intrinsics? They do have "rounding mode" and "exception behavior" metadata, but I don't really see how that maps onto the behavior of instructions
as described above. Also, right now the back-end doesn't even *get* at that data in the first place, since it is just thown away when lowering the intrinsics to STRICT_... nodes. In fact, I'm also not sure how the front-end is even supposed to be *setting*
those metadata flags -- is the compiler supposed to track calls to fesetround and the like, and thereby determine which rounding and exception modes apply to any given block of code? In fact, was the original intention even that the back-end actually implements
different behavior based on this level of detail, or was the back-end supposed to support only two modes, the default behavior of today and a fully strict implementation always satisfying all three of A), B), and C) above?</span><br>
<br>
<span style="font-size:10.0pt">Looking again at a possible implementation in the back-end, I'm now wondering if it wouldn't after all be better to just treat the STRICT_ opcodes like all other DAG nodes. That is, have them be associated with an action (Legal,
Expand, or Custom); set the default action to Expand, with a default expander that just replaces them by the "normal" FP nodes; and allow a back-end to set the action to Legal and/or Custom and then just handle them in the back-end as it sees fit. This might
indeed require multiple patterns to match them, but it should be possible to generate those via multiclass instantiations so it might not be all that big a deal. The benefit would be that it allows the back-end the greatest freedom how to handle things (e.g.
interactions with target-specific control registers).</span><br>
<br>
<span style="font-size:10.0pt"><br>
Mit freundlichen Gruessen / Best Regards<br>
<br>
Ulrich Weigand<br>
<br>
-- <br>
Dr. Ulrich Weigand | Phone: +49-7031/16-3727<br>
STSM, GNU/Linux compilers and toolchain<br>
IBM Deutschland Research & Development GmbH<br>
Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk Wittkopp<br>
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294</span><br>
<br>
<img width="16" height="16" id="_x0000_i1025" src="cid:image001.gif@01D3A1B6.D91E0760" alt="Inactive hide details for "Kaylor, Andrew" ---09.01.2018 19:55:59---I think we're going to need to create a new mechanism to co"><span style="font-size:10.0pt;color:#424282">"Kaylor,
Andrew" ---09.01.2018 19:55:59---I think we're going to need to create a new mechanism to communicate strict FP modes to the backend.</span><br>
<br>
<span style="font-size:10.0pt;color:#5F5F5F">From: </span><span style="font-size:10.0pt">"Kaylor, Andrew" <<a href="mailto:andrew.kaylor@intel.com">andrew.kaylor@intel.com</a>></span><br>
<span style="font-size:10.0pt;color:#5F5F5F">To: </span><span style="font-size:10.0pt">Ulrich Weigand <<a href="mailto:Ulrich.Weigand@de.ibm.com">Ulrich.Weigand@de.ibm.com</a>>, "<a href="mailto:kpn@neutralgood.org">kpn@neutralgood.org</a>" <<a href="mailto:kpn@neutralgood.org">kpn@neutralgood.org</a>></span><br>
<span style="font-size:10.0pt;color:#5F5F5F">Cc: </span><span style="font-size:10.0pt">Hal Finkel <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>>, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>>, "<a href="mailto:bob.huemmer@sas.com">bob.huemmer@sas.com</a>"
<<a href="mailto:bob.huemmer@sas.com">bob.huemmer@sas.com</a>>, "<a href="mailto:bumblebritches57@gmail.com">bumblebritches57@gmail.com</a>" <<a href="mailto:bumblebritches57@gmail.com">bumblebritches57@gmail.com</a>>, "<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>>, llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>></span><br>
<span style="font-size:10.0pt;color:#5F5F5F">Date: </span><span style="font-size:10.0pt">09.01.2018 19:55</span><br>
<span style="font-size:10.0pt;color:#5F5F5F">Subject: </span><span style="font-size:10.0pt">RE: [cfe-dev] Why is #pragma STDC FENV_ACCESS not supported?</span><o:p></o:p></p>
<div class="MsoNormal">
<hr size="2" width="100%" noshade="" style="color:#8091A5" align="left">
</div>
<p class="MsoNormal"><br>
<br>
<br>
<span style="font-family:"Calibri",sans-serif;color:#1F497D">I think we’re going to need to create a new mechanism to communicate strict FP modes to the backend. I think we need to avoid doing anything that will require re-inventing or duplicating all of the
pattern matching that goes on in instruction selection (which is the reason we’re currently dropping that information). I’m out of my depth on this transition, but I think maybe we could handle it with some kind of attribute on the MBB.</span><br>
<br>
<span style="font-family:"Calibri",sans-serif;color:#1F497D">In C/C++, at least, it’s my understanding that the pragmas always apply at the scope-level (as opposed to having the possibility of being instruction-specific), and we’ve previously agreed that our
implementation will really need to apply the rules across entire functions in the sense that if any part of a function uses the constrained intrinsics all FP operations in the function will need to use them (though different metadata arguments may be used
in different scopes). So I think that opens our options a bit.</span><br>
<br>
<span style="font-family:"Calibri",sans-serif;color:#1F497D">Regarding constant folding, I think you are correct that it isn’t happening anywhere in the backends at the moment. There is some constant folding done during instruction selection, but the existing
mechanism prevents that. My concern is that given LLVM’s development model, if there is nothing in place to prevent constant folding and no consensus that it shouldn’t be allowed then we should probably believe that someone will eventually do it.</span><br>
<br>
<span style="font-family:"Calibri",sans-serif;color:#1F497D">-Andy</span><br>
<br>
<b><span style="font-family:"Calibri",sans-serif">From:</span></b><span style="font-family:"Calibri",sans-serif"> Ulrich Weigand [<a href="mailto:Ulrich.Weigand@de.ibm.com">mailto:Ulrich.Weigand@de.ibm.com</a>]
<b><br>
Sent:</b> Tuesday, January 09, 2018 9:59 AM<b><br>
To:</b> Kaylor, Andrew <<a href="mailto:andrew.kaylor@intel.com">andrew.kaylor@intel.com</a>>;
<a href="mailto:kpn@neutralgood.org">kpn@neutralgood.org</a><b><br>
Cc:</b> Hal Finkel <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>>; Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>>;
<a href="mailto:bob.huemmer@sas.com">bob.huemmer@sas.com</a>; <a href="mailto:bumblebritches57@gmail.com">
bumblebritches57@gmail.com</a>; <a href="mailto:wei.ding2@amd.com">wei.ding2@amd.com</a>;
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>; llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>><b><br>
Subject:</b> Re: [cfe-dev] Why is #pragma STDC FENV_ACCESS not supported?</span><o:p></o:p></p>
<p><span style="font-size:10.0pt">Andrew Kaylor wrote:</span><br>
<span style="font-size:10.0pt;font-family:"Courier New""><br>
>In general, the current "strict FP" handling stops at instruction<br>
>selection. At the MachineIR level we don't currently have a mechanism<br>
>to prevent inappropriate optimizations based on floating point<br>
>constraints, or indeed to convey such constraints to the backend.<br>
>Implicit register use modeling may provide some restriction on some<br>
>architectures, but this is definitely lacking for X86 targets. On the<br>
>other hand, I'm not aware of any specific current problems, so in many<br>
>cases we may "get lucky" and have the correct thing happen by chance.<br>
>Obviously that's not a viable long term solution. I have a rough plan<br>
>for adding improved register modeling to the X86 backend, which should<br>
>take care of instruction scheduling issues, but we'd still need a<br>
>mechanism to prevent constant folding optimizations and such.</span><span style="font-size:10.0pt"><br>
<br>
Given that Kevin intends to target SystemZ, I'll be happy to work on the SystemZ back-end support for this feature. I agree that we should be using implicit control register dependencies, which will at least prevent moving floating-point operations across instructions
that e.g. change rounding modes. However, the main property we need to model is that floating-point operations may *trap*. I guess this can be done using UnmodeledSideEffects, but I'm not quite clear on how to make this dependent on whether or not a "strict"
operation is requested (without duplicating all the instruction patterns ...).</span><br>
<span style="font-size:10.0pt"><br>
Once we do use something like UnmodeledSideEffects, I think MachineIR passes should handle everything correctly; in the end, the requirements are not really different from those of other trapping instructions. B.t.w. I don't think anybody does constant folding
on floating-point constants at the MachineIR level anyway ... have you seen this anywhere?</span><br>
<span style="font-size:10.0pt"><br>
<br>
Mit freundlichen Gruessen / Best Regards<br>
<br>
Ulrich Weigand<br>
<br>
-- <br>
Dr. Ulrich Weigand | Phone: +49-7031/16-3727<br>
STSM, GNU/Linux compilers and toolchain<br>
IBM Deutschland Research & Development GmbH<br>
Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk Wittkopp<br>
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294</span><o:p></o:p></p>
<p><o:p> </o:p></p>
</div>
</body>
</html>