<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">If everyone's happy with that approach, I agree we're ready to start looking at the frontend side of things :-) I think there are a few open questions:</div><div class="gmail_quote"><div><br></div><div>* Is it ever worth outlining an FENV_ACCESS block from a function to minimize the scope in which optimizations are restricted? (Presumably in the long term, all the LLVM optimizations that can operate on FP operations will do the same thing to intrinsic calls that are in "never traps, rounds to nearest" mode, so it may well not be worthwhile.)</div><div>* What impact does FENV_ACCESS have on constant expression evaluation, particularly in C++11 onwards where some FP operations are required to be evaluated during compilation?</div><div>* What happens if FENV_ACCESS is enabled at the end of a module?</div><div>* How does FENV_ACCESS interact with namespaces? Does it only last until the `}` (like at block scope) or not?</div><div><br></div><div>I've taken some of these to the C++ committee to see if they have opinions about how this feature should work in C++.</div><div><br></div></div><div class="gmail_quote">On 31 August 2017 at 15:28, 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="white" lang="EN-US">
<div class="gmail-m_6316069171635759043WordSection1">
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">This sounds promising.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">I would not that when I added the strictfp attribute, I intended that the front end would attach this attribute to the callsite of all function calls within a
scope that required strict floating point semantics. It was supposed to be a way of preventing calls to libm functions from being optimized as LibFunc calls without the front end needing to know which functions could be processed that way.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">I think it is a natural extension to use this attribute on functions that contain code requiring strict floating point handling<a name="m_6316069171635759043__MailEndCompose">, but
the documentation will need to be updated.<u></u><u></u></a></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11pt;font-family:Calibri,sans-serif;color:windowtext">From:</span></b><span style="font-size:11pt;font-family:Calibri,sans-serif;color:windowtext"> Hal Finkel [mailto:<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>]
<br>
<b>Sent:</b> Thursday, August 31, 2017 3:08 PM<br>
<b>To:</b> Richard Smith <<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>><br>
<b>Cc:</b> Kaylor, Andrew <<a href="mailto:andrew.kaylor@intel.com" target="_blank">andrew.kaylor@intel.com</a>>; 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></p><div><div class="gmail-h5"><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><div><div class="gmail-h5">
<p class="MsoNormal"><u></u> <u></u></p>
<p><u></u> <u></u></p>
<div>
<p class="MsoNormal">On 08/31/2017 05:02 PM, Richard Smith wrote:<u></u><u></u></p>
</div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<div>
<div>
<p class="MsoNormal">On 31 August 2017 at 14:40, Hal Finkel 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-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<p>On 08/31/2017 04:31 PM, Richard Smith via cfe-dev wrote:<u></u><u></u></p>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<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>
</blockquote>
<p class="MsoNormal"><br>
Or we prevent inlining.<u></u><u></u></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Sure, I was considering that to be a form of interprocedural code motion :)<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<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>
</blockquote>
<p class="MsoNormal"><br>
Good point. However, that's not a new problem, and we currently deal with this by respecting the noimplicitfloat attribute (and I think we'd definitely need to use that attribute if we allow fooling with the FP environment).<u></u><u></u></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">OK, so the idea would be that we'd lower a function containing FENV_ACCESS (or possibly an outlined block of such a function) with intrinsics for all FP operations, specially-annotated libm function calls, and noimplicitfloat and strictfp
attributes to prevent generation of new FP operations and inlining into non-strictfp functions. Right? (And we could imagine a verifier check that ensures that you don't have pure FP operations inside a strictfp function.)<u></u><u></u></p>
</div>
</div>
</div>
</div>
</blockquote>
<p class="MsoNormal"><br>
Yes, exactly.<br>
<br>
<br>
<u></u><u></u></p>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<div>
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Given the function annotations, do we need special intrinsics at all, or could we instead require that passes check whether the enclosing function is marked strictfp before optimizing, in the same way that some optimizations must be gated
by a check for noimplicitfloat?<u></u><u></u></p>
</div>
</div>
</div>
</div>
</blockquote>
<p class="MsoNormal"><br>
That's another possible design. We decided that the intrinsics were less intrusive. The problems is that it's not just FP-specific optimizations that would need to check the attribute, it is also other optimizations doing other kinds of code motion and value
propagation. Having IR-level operations that are side-effect-free, except when some special function attribute is present, seems undesirable.<br>
<br>
-Hal<br>
<br>
<br>
<u></u><u></u></p>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal"> -Hal <u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"><br>
<br>
<br>
<u></u><u></u></p>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<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-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">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"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p class="MsoNormal"><b><span style="font-size:11pt;font-family:Calibri,sans-serif">From:</span></b><span style="font-size:11pt;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-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt">
<div>
<div>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">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:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span><u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt">
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:11pt;font-family:Calibri,sans-serif">From:</span></b><span style="font-size:11pt;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-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt">
<div>
<div>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">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:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">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:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><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:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">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:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">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="gmail-m_6316069171635759043m-23198277102369654m-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="gmail-m_6316069171635759043m-23198277102369654m-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:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span><u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt">
<div>
<div>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">-Andy</span><u></u><u></u></p>
<p class="MsoNormal"><a name="m_6316069171635759043_m_-23198277102369654_m_-2075974219545047"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span></a><u></u><u></u></p>
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11pt;font-family:Calibri,sans-serif">From:</span></b><span style="font-size:11pt;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:5pt;margin-bottom:5pt">
<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:12pt"><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:5pt;margin-bottom:5pt">
<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-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt">
<div>
<div>
<p class="MsoNormal"><span style="font-size:18pt">^^^^^^</span><u></u><u></u></p>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12pt"><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:12pt"> <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:12pt"> <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:12pt">______________________________<wbr>_________________ cfe-dev mailing list
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>
<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:12pt">______________________________<wbr>_________________ cfe-dev mailing list
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>
<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">______________________________<wbr>_________________ cfe-dev mailing list
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>
<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>
</div>
</div>
</div>
<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>
<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>
<p class="MsoNormal">______________________________<wbr>_________________ cfe-dev mailing list
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a> <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>
</div>
</blockquote>
<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>
<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>