<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<div class="moz-cite-prefix">On 08/31/2017 05:41 PM, Richard Smith
wrote:<br>
</div>
<blockquote
cite="mid:CAOfiQq=B_q6doPZYaM-5j0GwZyoDGCM1p9VE1YERqvftSgFYSw@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<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>
</div>
</div>
</blockquote>
<br>
Outlining is probably a reasonable idea if there are floating-point
computations outside of the FENV_ACCESS blocks in the functions. The
tradeoffs here could be tricky, however, and I'd suggest waiting
until we find some motivating cases. Even long term, I don't expect
parity (just because if we're going to teach all of the
transformations to treat them identically, we might as well extend
the semantics of the IR operations themselves, and it's not clear to
me that will even be worthwhile).<br>
<br>
<blockquote
cite="mid:CAOfiQq=B_q6doPZYaM-5j0GwZyoDGCM1p9VE1YERqvftSgFYSw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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>
</div>
</div>
</blockquote>
<br>
Would you prefer that it stay within the module? I think I'd prefer
that.<br>
<br>
Thanks again,<br>
Hal<br>
<br>
<blockquote
cite="mid:CAOfiQq=B_q6doPZYaM-5j0GwZyoDGCM1p9VE1YERqvftSgFYSw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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
moz-do-not-send="true"
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.</span></p>
<p class="MsoNormal"><span
style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </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.</span></p>
<p class="MsoNormal"><span
style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </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
moz-do-not-send="true"
name="m_6316069171635759043__MailEndCompose">,
but the documentation will need to be updated.</a></span></p>
<p class="MsoNormal"><span
style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </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 moz-do-not-send="true"
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
moz-do-not-send="true"
href="mailto:richard@metafoo.co.uk"
target="_blank">richard@metafoo.co.uk</a>><br>
<b>Cc:</b> Kaylor, Andrew <<a
moz-do-not-send="true"
href="mailto:andrew.kaylor@intel.com"
target="_blank">andrew.kaylor@intel.com</a>>;
Marcus Johnson <<a moz-do-not-send="true"
href="mailto:bumblebritches57@gmail.com"
target="_blank">bumblebritches57@gmail.com</a>>;
Clang Dev <<a moz-do-not-send="true"
href="mailto:cfe-dev@lists.llvm.org"
target="_blank">cfe-dev@lists.llvm.org</a>>;
<a moz-do-not-send="true"
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?</div>
</div>
</div>
</div>
<div>
<div class="gmail-h5">
<p class="MsoNormal"> </p>
<p> </p>
<div>
<p class="MsoNormal">On 08/31/2017 05:02 PM,
Richard Smith wrote:</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
moz-do-not-send="true"
href="mailto:cfe-dev@lists.llvm.org"
target="_blank">cfe-dev@lists.llvm.org</a>>
wrote:</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:</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.</p>
</div>
</blockquote>
<p class="MsoNormal"><br>
Or we prevent inlining.</p>
</div>
</blockquote>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Sure, I was
considering that to be a form of
interprocedural code motion :)</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.</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).</p>
</div>
</blockquote>
<div>
<p class="MsoNormal"> </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.)</p>
</div>
</div>
</div>
</div>
</blockquote>
<p class="MsoNormal"><br>
Yes, exactly.<br>
<br>
<br>
</p>
<blockquote
style="margin-top:5pt;margin-bottom:5pt">
<div>
<div>
<div>
<div>
<p class="MsoNormal"> </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?</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>
</p>
<blockquote
style="margin-top:5pt;margin-bottom:5pt">
<div>
<div>
<div>
<div>
<p class="MsoNormal"> </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 </p>
<div>
<div>
<p class="MsoNormal"><br>
<br>
<br>
</p>
<blockquote
style="margin-top:5pt;margin-bottom:5pt">
<div>
<div>
<div>
<p class="MsoNormal"> </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.
</p>
<div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">On
31 August 2017 at
14:20, Kaylor,
Andrew via cfe-dev
<<a
moz-do-not-send="true"
href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>>
wrote:</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></p>
<p
class="MsoNormal"><span
style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span></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
moz-do-not-send="true"
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
moz-do-not-send="true"
href="mailto:andrew.kaylor@intel.com" target="_blank">andrew.kaylor@intel.com</a>><br>
<b>Cc:</b>
Clang Dev <<a
moz-do-not-send="true" href="mailto:cfe-dev@lists.llvm.org"
target="_blank">cfe-dev@lists.llvm.org</a>>;
Marcus Johnson
<<a
moz-do-not-send="true"
href="mailto:bumblebritches57@gmail.com" target="_blank">bumblebritches57@gmail.com</a>>;
<a
moz-do-not-send="true"
href="mailto:wei.ding2@amd.com" target="_blank">wei.ding2@amd.com</a></span></p>
<div>
<div>
<p
class="MsoNormal"><br>
<b>Subject:</b>
Re: [cfe-dev]
Why is #pragma
STDC
FENV_ACCESS
not supported?</p>
</div>
</div>
<div>
<div>
<p
class="MsoNormal"> </p>
<div>
<div>
<div>
<p
class="MsoNormal">On
31 August 2017
at 14:14,
Kaylor, Andrew
via cfe-dev
<<a
moz-do-not-send="true"
href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>>
wrote:</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></p>
</div>
</div>
</blockquote>
<div>
<p
class="MsoNormal"> </p>
</div>
<div>
<p
class="MsoNormal">fadd
can be hoisted
past
*anything*,
can't it?</p>
</div>
<div>
<p
class="MsoNormal"><span
style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span></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
moz-do-not-send="true"
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
moz-do-not-send="true"
href="mailto:andrew.kaylor@intel.com" target="_blank">andrew.kaylor@intel.com</a>><br>
<b>Cc:</b>
Marcus Johnson
<<a
moz-do-not-send="true"
href="mailto:bumblebritches57@gmail.com" target="_blank">bumblebritches57@gmail.com</a>>;
Clang Dev <<a
moz-do-not-send="true" href="mailto:cfe-dev@lists.llvm.org"
target="_blank">cfe-dev@lists.llvm.org</a>>;
<a
moz-do-not-send="true"
href="mailto:wei.ding2@amd.com" target="_blank">wei.ding2@amd.com</a></span></p>
<div>
<div>
<p
class="MsoNormal"><br>
<b>Subject:</b>
Re: [cfe-dev]
Why is #pragma
STDC
FENV_ACCESS
not supported?</p>
</div>
</div>
<div>
<div>
<p
class="MsoNormal"> </p>
<div>
<div>
<div>
<p
class="MsoNormal">On
31 August 2017
at 11:09,
Kaylor, Andrew
via cfe-dev
<<a
moz-do-not-send="true"
href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>>
wrote:</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></p>
<p
class="MsoNormal"><span
style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span></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></p>
<p
class="MsoNormal"><span
style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span></p>
<p
class="MsoNormal"><span
style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><a
moz-do-not-send="true" href="https://reviews.llvm.org/D27028"
target="_blank">https://reviews.llvm.org/<wbr>D27028</a></span></p>
<p
class="MsoNormal"><span
style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span></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></p>
<p
class="MsoNormal"><span
style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span></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></p>
</div>
</div>
</blockquote>
<div>
<p
class="MsoNormal"> </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></p>
</div>
<div>
<p
class="MsoNormal"><span
style="font-size:9.5pt"> </span></p>
</div>
<div>
<p
class="MsoNormal"><span
style="font-size:9.5pt">double f(double a, double b, double c) {</span></p>
</div>
<div>
<p
class="MsoNormal"><span
style="font-size:9.5pt"> {</span></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></p>
</div>
<div>
<p
class="MsoNormal"><span
style="font-size:9.5pt"> feenableexcept(FE_OVERFLOW);</span></p>
</div>
<div>
<p
class="MsoNormal"><span
style="font-size:9.5pt"> double d = a * b;</span></p>
</div>
<div>
<p
class="MsoNormal"><span
style="font-size:9.5pt"> fedisableexcept(FE_OVERFLOW);</span></p>
</div>
<div>
<p
class="MsoNormal"><span
style="font-size:9.5pt"> }</span></p>
</div>
<div>
<p
class="MsoNormal"><span
style="font-size:9.5pt"> return c * d;</span></p>
</div>
<div>
<p
class="MsoNormal"><span
style="font-size:9.5pt">}</span></p>
</div>
<div>
<p
class="MsoNormal"><span
style="font-size:9.5pt"> </span></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></p>
</div>
</div>
<div>
<p
class="MsoNormal"><span
style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span></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></p>
<p
class="MsoNormal"><a
moz-do-not-send="true"
name="m_6316069171635759043_m_-23198277102369654_m_-2075974219545047"><span
style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span></a></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
moz-do-not-send="true"
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
moz-do-not-send="true"
href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>>;
Marcus Johnson
<<a
moz-do-not-send="true"
href="mailto:bumblebritches57@gmail.com" target="_blank">bumblebritches57@gmail.com</a>><br>
<b>Cc:</b>
Clang Dev <<a
moz-do-not-send="true" href="mailto:cfe-dev@lists.llvm.org"
target="_blank">cfe-dev@lists.llvm.org</a>>;
Kaylor, Andrew
<<a
moz-do-not-send="true"
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></p>
</div>
</div>
<div>
<div>
<p
class="MsoNormal"> </p>
<p> </p>
<div>
<p
class="MsoNormal">On
08/31/2017
12:10 PM,
Richard Smith
via cfe-dev
wrote:</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.</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</p>
<blockquote
style="margin-top:5pt;margin-bottom:5pt">
<div>
<p
class="MsoNormal"> </p>
<div>
<p
class="MsoNormal">On
31 Aug 2017
10:06, "Marcus
Johnson via
cfe-dev" <<a
moz-do-not-send="true" href="mailto:cfe-dev@lists.llvm.org"
target="_blank">cfe-dev@lists.llvm.org</a>>
wrote:</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></p>
</div>
</div>
<p
class="MsoNormal"
style="margin-bottom:12pt"><br>
______________________________<wbr>_________________<br>
cfe-dev
mailing list<br>
<a
moz-do-not-send="true"
href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a
moz-do-not-send="true"
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></p>
</blockquote>
</div>
</div>
<p
class="MsoNormal"
style="margin-bottom:12pt"> </p>
<pre>______________________________<wbr>_________________</pre>
<pre>cfe-dev mailing list</pre>
<pre><a moz-do-not-send="true" href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a></pre>
<pre><a moz-do-not-send="true" 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></pre>
</blockquote>
<p class="MsoNormal" style="margin-bottom:12pt"> </p>
<pre>-- </pre>
<pre>Hal Finkel</pre>
<pre>Lead, Compiler Technology and Programming Languages</pre>
<pre>Leadership Computing Facility</pre>
<pre>Argonne National Laboratory</pre>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12pt">______________________________<wbr>_________________ cfe-dev mailing list
<a moz-do-not-send="true" href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>
<a moz-do-not-send="true" 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></p>
</blockquote>
</div>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12pt">______________________________<wbr>_________________ cfe-dev mailing list
<a moz-do-not-send="true" href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>
<a moz-do-not-send="true" 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></p>
</blockquote>
</div>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal">______________________________<wbr>_________________ cfe-dev mailing list
<a moz-do-not-send="true" href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>
<a moz-do-not-send="true" 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> </p>
</blockquote>
</div>
</div>
</div>
</div>
</div>
<pre>______________________________<wbr>_________________</pre>
<pre>cfe-dev mailing list</pre>
<pre><a moz-do-not-send="true" href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a></pre>
<pre><a moz-do-not-send="true" 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></pre>
</blockquote>
<pre>-- </pre>
<pre>Hal Finkel</pre>
<pre>Lead, Compiler Technology and Programming Languages</pre>
<pre>Leadership Computing Facility</pre>
<pre>Argonne National Laboratory</pre>
</div>
</div>
</div>
<p class="MsoNormal">______________________________<wbr>_________________ cfe-dev mailing list
<a moz-do-not-send="true" href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a> <a moz-do-not-send="true" 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> </p>
</blockquote>
</div>
</div>
</div>
</blockquote>
<pre>-- </pre>
<pre>Hal Finkel</pre>
<pre>Lead, Compiler Technology and Programming Languages</pre>
<pre>Leadership Computing Facility</pre>
<pre>Argonne National Laboratory</pre>
</div></div></div>
</div>
______________________________<wbr>_________________
cfe-dev mailing list
<a moz-do-not-send="true" href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>
<a moz-do-not-send="true" 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>
</blockquote></div>
</div></div>
</blockquote>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre></body></html>