<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-m-1510330375827564095gmail-m-4692219112205293189apple-converted-space
{mso-style-name:gmail-m_-1510330375827564095gmail-m_-4692219112205293189apple-converted-space;}
span.EmailStyle19
{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"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><b>From:</b> Cameron McInally <cameron.mcinally@nyu.edu>
<br>
<b>Sent:</b> Friday, June 14, 2019 5:40 PM<br>
<b>To:</b> Chris Lattner <clattner@nondot.org><br>
<b>Cc:</b> Eli Friedman <efriedma@quicinc.com>; llvm-dev <llvm-dev@lists.llvm.org><br>
<b>Subject:</b> [EXT] Re: [llvm-dev] Planned change to IR semantics: constant expressions never have undefined behavior<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in">On Fri, Jun 14, 2019 at 7:10 PM Chris Lattner <<a href="mailto:clattner@nondot.org">clattner@nondot.org</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">
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="margin-left:.5in"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="margin-left:.5in">On Jun 14, 2019, at 4:06 PM, Cameron McInally <<a href="mailto:cameron.mcinally@nyu.edu" target="_blank">cameron.mcinally@nyu.edu</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in">On Fri, Jun 14, 2019 at 6:58 PM Chris Lattner 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-right:0in">
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="margin-left:.5in"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="margin-left:.5in">On Jun 14, 2019, at 3:24 PM, Eli Friedman 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>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in">See<span class="gmail-m-1510330375827564095gmail-m-4692219112205293189apple-converted-space"> </span><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D63036&d=DwMFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=O_4M49EtSpZ_-BQYeigzGv0P4__noMcSu2RYEjS1vKs&m=HPH8LbjOYmP3G9p6HJYKLtOFGQQJ0aWeEc7QU46PkOw&s=Q-PK-STEJTkFgcTQeOjIR7RY4e_iIHz191Qk_8syQlA&e=" target="_blank"><span style="color:#954F72">https://reviews.llvm.org/D63036</span></a><span class="gmail-m-1510330375827564095gmail-m-4692219112205293189apple-converted-space"> </span>for
the full patch and description. Essentially, the Constant::canTrap API is going away. To make this work, the semantics of division and remainder constant expressions are changing slightly, so division by zero produces poison, not undefined behavior. (The
corresponding instructions still have undefined behavior.) This change should make writing and understanding IR optimizations easier.<o:p></o:p></p>
</div>
</div>
</div>
</blockquote>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">Is anyone interested and willing to make a more profound change to llvm’s constants? We should really remove all the trapping operators. The only reason they exist in the first place is to allow use of Constant::get()
as a high level constant folding API. We could replace that, eliminate the trapping operators, and thus eliminate a ton of complexity and bugs…<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">Hi Chris,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">If I'm understanding your proposal correctly, the constrained FP intrinsic work could make use of that code -- in the future. Eventually we'll want to optimize the constrained FP intrinsics and being able to constant
fold non-trapping instructions is important.<o:p></o:p></p>
</div>
</div>
</div>
</div>
</blockquote>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">Right: in terms of primary constant folding entry points, the ConstExpr::get sort of methods have always been a mistake (and I’ve never gotten around to fixing them).<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">Ok, I think I understand now. So we'd retain the ability to constant fold operations that may trap, possibly returning trap flags, through APFloat. If that's correct, that would work for the constrained FP intrinsics
project. No big deal.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Yes, this would be specifically about the entry points that produce a ConstantExpr.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> <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="margin-left:.5in">A better thing to do is to make ConstExpr’s have their own enum of “operations”, and make them correspond to the things that show up in a global variable initializer (e.g. relocatable expressions). There is no reason
for constant expressions to mirror the instruction enum, and there is lots of harm caused by it.<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">You may have lost me here, but that's ok. If you're suggesting not switching on the Instruction OpCodes in ConstantExpr::get(...) et al, to encapsulate the ConstantExpr class, then +1 from me.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The idea here is actually to eliminate the underlying expressions themselves, so it would no longer be legal to write “sdiv (i32 […], i32 […])” as a constant expression at all in IR.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The hardest part of this is probably figuring out how to handle AutoUpgrade; there aren’t that many transforms which actually try to create an sdiv constant expression, and it shouldn’t be too hard to make them fail gracefully.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">-Eli<o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>