<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 31 August 2017 at 14:48, Kaylor, Andrew via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-US" link="blue" vlink="purple">
<div class="m_1672052445564938120WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">I had considered the inlining issue, and updating the inliner to handle this was on my list of things yet to be done.  I’m not sure I understand what you’re saying
 about LTO. </span></p></div></div></blockquote><div><br></div><div>The point about LTO was that you can't solve the inlining problem by using intrinsics throughout an entire module if FENV_ACCESS is used anywhere, because you might see code from outside the module.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_1672052445564938120WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">There are some points about the standard specification that seem a bit unclear to me, specifically with regard to how things work if you call an FENV_ACCESS-off
 function from within an FENV_ACCESS-on scope.  I believe that when I talked with our front end guys here about that our conclusion was that doing that sort of thing is undefined behavior.  I’m not sure if this is related to your LTO concern or not.</span></p></div></div></blockquote><div><br></div><div>I don't think that observation helps much, since you can call FENV_ACCESS-on code from FENV_ACCESS-off code, which is equally problematic. It's also not true that the above case results in UB: you only get UB if you're in a non-default FP mode when you enter the FENV_ACCESS-off code, or if that code attempts to inspect or alter the FP environment -- so the hoisting problem still seems to exist.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_1672052445564938120WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">In any event, you definitely raise some good questions that I don’t have answers for.  I’ll have to give this some more thought.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">I just want to add that one of the primary design goals in what I’ve done so far was to not doing anything that would inhibit optimizations or require extra work
 on the part of the optimization passes in the case where we don’t care about FENV_ACCESS.  That requirement makes attaching side-effects to the FP operations quite difficult.</span></p></div></div></blockquote><div><br></div><div>Indeed; FWIW that approach seems like the right one to me. We need a very strong barrier between anything that might use feenableexcept and anything that might use LLVM's "pure" FP operations, and I don't believe we have such a thing in LLVM IR yet. So I don't think we're ready for frontend work on FENV_ACCESS, since we don't yet know how it will be represented in IR.</div><div><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt"> </span></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_1672052445564938120WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">-Andy<u></u><u></u></span></p>
<p class="MsoNormal"><a name="m_1672052445564938120__MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></a></p>
<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"> Richard Smith [mailto:<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>]
<br>
<b>Sent:</b> Thursday, August 31, 2017 2:32 PM</span></p><div><div class="h5"><br>
<b>To:</b> Kaylor, Andrew <<a href="mailto:andrew.kaylor@intel.com" target="_blank">andrew.kaylor@intel.com</a>><br>
<b>Cc:</b> Marcus Johnson <<a href="mailto:bumblebritches57@gmail.com" target="_blank">bumblebritches57@gmail.com</a>>; Clang Dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>>; <a href="mailto:wei.ding2@amd.com" target="_blank">wei.ding2@amd.com</a><br>
<b>Subject:</b> Re: [cfe-dev] Why is #pragma STDC FENV_ACCESS not supported?<u></u><u></u></div></div><p></p><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">I think that's also not enough; you'd get the same problem after inlining, and across modules with LTO. You would need to also prevent any interprocedural code motion across a FENV_ACCESS / non-FENV_ACCESS boundary.<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">And even that doesn't seem to be enough. Suppose that some scalar optimization pass finds a clever way to converts some integer operation into a floating-point operation, such that it can prove that the FP values never overflow (I believe
 Chandler has an example of this that comes up in some real crypto code). Now suppose there's a case where the integer operands are undef, but that the code in question is bypassed in that case. If the FP operations get hoisted, and you happen to have FP exceptions
 enabled, you have a potential miscompile.<u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Fundamentally, it seems to me that feenableexcept is unsound in the current LLVM IR model of floating point, if we assume that fadd, fmul, fsub etc do not have side-effects.<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On 31 August 2017 at 14:20, Kaylor, Andrew via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<u></u><u></u></p>
<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"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">If that’s the case, we may need to use the constrained intrinsics for all FP operations when FENV_ACCESS
 is enabled anywhere in a function.</span><u></u><u></u></p>
<p class="MsoNormal"><a name="m_1672052445564938120_m_-2075974219545047674__MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span></a><u></u><u></u></p>
<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"> Richard Smith [mailto:<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>]
<br>
<b>Sent:</b> Thursday, August 31, 2017 2:18 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> Clang Dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>>; Marcus Johnson <<a href="mailto:bumblebritches57@gmail.com" target="_blank">bumblebritches57@gmail.com</a>>;
<a href="mailto:wei.ding2@amd.com" target="_blank">wei.ding2@amd.com</a></span><u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"><br>
<b>Subject:</b> Re: [cfe-dev] Why is #pragma STDC FENV_ACCESS not supported?<u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<div>
<p class="MsoNormal">On 31 August 2017 at 14:14, Kaylor, Andrew via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<u></u><u></u></p>
<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"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">I believe that we will rely on fedisableexcept() being marked as having unmodeled side-effects to prevent
 a hoist like that.</span><u></u><u></u></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">fadd can be hoisted past *anything*, can't it?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></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"><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"> Richard Smith [mailto:<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>]
<br>
<b>Sent:</b> Thursday, August 31, 2017 2:09 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> Marcus Johnson <<a href="mailto:bumblebritches57@gmail.com" target="_blank">bumblebritches57@gmail.com</a>>; Clang Dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>>;
<a href="mailto:wei.ding2@amd.com" target="_blank">wei.ding2@amd.com</a></span><u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"><br>
<b>Subject:</b> Re: [cfe-dev] Why is #pragma STDC FENV_ACCESS not supported?<u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<div>
<p class="MsoNormal">On 31 August 2017 at 11:09, Kaylor, Andrew via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<u></u><u></u></p>
<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"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">There are still a few things missing from the optimizer to get it completely robust, but I think there
 is enough in place for front end work to begin.  As I think I’ve demonstrated in my recent attempt to contribute a clang patch I’m not skilled enough with the front end to be the person to pull this off without an excessive amount of oversight, but as Erich
 indicated we do have some good front end people here who have this on their TODO list.  It’s just not at the top of the TODO list yet.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">If anyone is interested in the details of the LLVM side of things, there are constrained FP intrinisics
 (still marked as experimental at this point) documented in the language reference.  The initial patch can be seen here:</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><a href="https://reviews.llvm.org/D27028" target="_blank">https://reviews.llvm.org/<wbr>D27028</a></span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">I’ve since added another group of intrinsics to handle the libm-equivalent intrinsics, and more recently
 Wei Ding contributed an fma intrinsic.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">The idea is that the front end will emit the constrained intrinsics in place of equivalent general
 FP operations or intrinsics in scopes where FENV_ACCESS is enabled.  This will prevent the optimizer from making optimizations that assume default fenv settings (which is what we want the optimizer to do in all other cases).  Eventually, we’ll want to go back
 and teach specific optimizations to understand the intrinsics so that where possible optimizations can be performed in a manner consistent with dynamic rounding modes and strict exception handling.</span><u></u><u></u></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.5pt">How do you deal with the hoisting-into-<span class="m_1672052445564938120m-2075974219545047674m2724022782041152477gmail-il">fenv_access</span> <wbr>problem? Eg:</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.5pt"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.5pt">double f(double a, double b, double c) {</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.5pt">  {</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.5pt">#pragma STDC <span class="m_1672052445564938120m-2075974219545047674m2724022782041152477gmail-il">FENV_ACCESS</span> ON</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.5pt">    feenableexcept(FE_OVERFLOW);</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.5pt">    double d = a * b;</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.5pt">    fedisableexcept(FE_OVERFLOW);</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.5pt">  }</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.5pt">  return c * d;</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.5pt">}</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.5pt"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.5pt">What stops llvm from hoisting the second fmul up to before the fedisableexcept?</span><u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></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"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">-Andy</span><u></u><u></u></p>
<p class="MsoNormal"><a name="m_1672052445564938120_m_-2075974219545047674_m_272402278204115"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span></a><u></u><u></u></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"> Hal Finkel [mailto:<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>]
<br>
<b>Sent:</b> Thursday, August 31, 2017 10:45 AM<br>
<b>To:</b> Richard Smith <<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>>; Marcus Johnson <<a href="mailto:bumblebritches57@gmail.com" target="_blank">bumblebritches57@gmail.com</a>><br>
<b>Cc:</b> Clang Dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>>; Kaylor, Andrew <<a href="mailto:andrew.kaylor@intel.com" target="_blank">andrew.kaylor@intel.com</a>><br>
<b>Subject:</b> Re: [cfe-dev] Why is #pragma STDC FENV_ACCESS not supported?</span><u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<p> <u></u><u></u></p>
<div>
<p class="MsoNormal">On 08/31/2017 12:10 PM, Richard Smith via cfe-dev wrote:<u></u><u></u></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">Because no-one has implemented it. Patches would be welcome, but will need to start with a design and implementation of the requisite llvm extensions.<u></u><u></u></p>
</div>
</blockquote>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
Yes. This is what Andrew Kaylor has been working on (cc'd).<br>
<br>
 -Hal<u></u><u></u></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<p class="MsoNormal">On 31 Aug 2017 10:06, "Marcus Johnson via cfe-dev" <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<u></u><u></u></p>
<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"><span style="font-size:18.0pt">^^^^^^</span><u></u><u></u></p>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
______________________________<wbr>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><u></u><u></u></p>
</blockquote>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"> <u></u><u></u></p>
<pre>______________________________<wbr>_________________<u></u><u></u></pre>
<pre>cfe-dev mailing list<u></u><u></u></pre>
<pre><a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><u></u><u></u></pre>
<pre><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><u></u><u></u></pre>
</blockquote>
<p class="MsoNormal" style="margin-bottom:12.0pt"> <u></u><u></u></p>
<pre>-- <u></u><u></u></pre>
<pre>Hal Finkel<u></u><u></u></pre>
<pre>Lead, Compiler Technology and Programming Languages<u></u><u></u></pre>
<pre>Leadership Computing Facility<u></u><u></u></pre>
<pre>Argonne National Laboratory<u></u><u></u></pre>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
______________________________<wbr>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><u></u><u></u></p>
</blockquote>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
______________________________<wbr>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><u></u><u></u></p>
</blockquote>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
______________________________<wbr>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><u></u><u></u></p>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div>
</div>
</div></div></div>
</div>

<br>______________________________<wbr>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div></div>