<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=iso-8859-1">
<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:12.0pt;
font-family:"Times New Roman",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;}
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;}
tt
{mso-style-priority:99;
font-family:"Courier New";}
span.EmailStyle19
{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="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;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.<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">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.<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">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.<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">-Andy<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> Tuesday, January 09, 2018 9:59 AM<br>
<b>To:</b> Kaylor, Andrew <andrew.kaylor@intel.com>; kpn@neutralgood.org<br>
<b>Cc:</b> Hal Finkel <hfinkel@anl.gov>; Richard Smith <richard@metafoo.co.uk>; bob.huemmer@sas.com; bumblebritches57@gmail.com; wei.ding2@amd.com; cfe-dev@lists.llvm.org; llvm-dev <llvm-dev@lists.llvm.org><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">Andrew Kaylor wrote:</span><br>
<br>
<tt><span style="font-size:10.0pt">>In general, the current "strict FP" handling stops at instruction</span></tt><br>
<tt><span style="font-size:10.0pt">>selection. At the MachineIR level we don't currently have a mechanism</span></tt><br>
<tt><span style="font-size:10.0pt">>to prevent inappropriate optimizations based on floating point</span></tt><br>
<tt><span style="font-size:10.0pt">>constraints, or indeed to convey such constraints to the backend.</span></tt><br>
<tt><span style="font-size:10.0pt">>Implicit register use modeling may provide some restriction on some</span></tt><br>
<tt><span style="font-size:10.0pt">>architectures, but this is definitely lacking for X86 targets. On the</span></tt><br>
<tt><span style="font-size:10.0pt">>other hand, I'm not aware of any specific current problems, so in many</span></tt><br>
<tt><span style="font-size:10.0pt">>cases we may "get lucky" and have the correct thing happen by chance.</span></tt><br>
<tt><span style="font-size:10.0pt">>Obviously that's not a viable long term solution. I have a rough plan</span></tt><br>
<tt><span style="font-size:10.0pt">>for adding improved register modeling to the X86 backend, which should</span></tt><br>
<tt><span style="font-size:10.0pt">>take care of instruction scheduling issues, but we'd still need a</span></tt><br>
<tt><span style="font-size:10.0pt">>mechanism to prevent constant folding optimizations and such.</span></tt><br>
<span style="font-size:10.0pt"><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>
<br>
<span style="font-size:10.0pt">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>
<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><o:p></o:p></p>
</div>
</body>
</html>