<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.EmailStyle18
{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">This is fundamentally different than the problems we’re trying to handle with the constrained FP intrinsics. The constrained FP intrinsics were necessary because LLVM IR otherwise assumes that FP instructions do not have side effects. In
the case of integer divide-by-zero, the optimizer generally recognizes this as a possibility and avoids introducing it (through speculation, for instance). But if we’re optimizing it away as undefined behavior I guess that’s another story.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I’m not against introducing a way to handle that case, but I would be against making it look like the constrained FP intrinsics.<o:p></o:p></p>
<p class="MsoNormal"><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> Cameron McInally <cameron.mcinally@nyu.edu>
<br>
<b>Sent:</b> Saturday, June 15, 2019 7:04 AM<br>
<b>To:</b> Eli Friedman <efriedma@quicinc.com><br>
<b>Cc:</b> LLVM Developers Mailing List <llvm-dev@lists.llvm.org>; Craig Topper <craig.topper@gmail.com>; Kaylor, Andrew <andrew.kaylor@intel.com><br>
<b>Subject:</b> Re: Constrained integer DIV (WAS: Re: [llvm-dev] Planned change to IR semantics: constant expressions never have undefined behavior)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<div>
<p class="MsoNormal">On Fri, Jun 14, 2019 at 8:36 PM Eli Friedman <<a href="mailto:efriedma@quicinc.com">efriedma@quicinc.com</a>> wrote:<o:p></o:p></p>
</div>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">> -----Original Message-----<br>
> From: Cameron McInally <<a href="mailto:cameron.mcinally@nyu.edu" target="_blank">cameron.mcinally@nyu.edu</a>><br>
> Sent: Friday, June 14, 2019 4:02 PM<br>
> To: Eli Friedman <<a href="mailto:efriedma@quicinc.com" target="_blank">efriedma@quicinc.com</a>>; LLVM Developers Mailing List <llvm-<br>
> <a href="mailto:dev@lists.llvm.org" target="_blank">dev@lists.llvm.org</a>><br>
> Cc: Craig Topper <<a href="mailto:craig.topper@gmail.com" target="_blank">craig.topper@gmail.com</a>>; Kaylor, Andrew<br>
> <<a href="mailto:andrew.kaylor@intel.com" target="_blank">andrew.kaylor@intel.com</a>><br>
> Subject: [EXT] Constrained integer DIV (WAS: Re: [llvm-dev] Planned change to<br>
> IR semantics: constant expressions never have undefined behavior)<br>
> <br>
> On Fri, Jun 14, 2019 at 6:24 PM Eli Friedman via llvm-dev<br>
> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> > wrote:<br>
> <br>
> I don't mean to steal your thunder, Eli, but I'd like to propose that<br>
> we add constrained intrinsics for integer DIV (and maybe REM). Some<br>
> architectures, like x86, can trap on integer div-by-zero. I'd like to<br>
> have some way to access that behavior, even if the C/C++ Standards say<br>
> it's undefined behavior.<br>
> <br>
> We have a few dusty deck codes in-house that depend on this, so I'm<br>
> motivated to push our local changes upstream. That said, if no one else<br>
> finds value in this, we can keep it local.<br>
<br>
Do you really need a special way to represent this in IR? If you need a SIGFPE, the frontend can generate the equivalent of "if (x==0) raise(SIGFPE);", which is well-defined across all targets. If you really need a "real" trap, I guess we could expose the
x86 idiv as an intrinsic. <o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">A real trap would be preferred. I suspect that it would be difficult/expensive to set all the flags correctly (if that's even possible). E.g.:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">#include <stdio.h><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">#include <signal.h><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">void handle_sigfpe(int fpe) <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">{ printf("Caught signal %d\n", fpe); }<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">int main (void) {<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> signal(SIGFPE, handle_sigfpe);<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">#if TRAP<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> int x = 1/0;<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">#else<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> raise(SIGFPE);<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">#endif<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> return 0;<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">}<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">In this pathological case, the RF flag differs so we'll see an infinite loop.<o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>