<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<div class="moz-cite-prefix">On 03/15/2017 04:24 PM, Kaylor, Andrew
wrote:<br>
</div>
<blockquote
cite="mid:0983E6C011D2DC4188F8761B533492DE576FADB2@ORSMSX115.amr.corp.intel.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<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;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;
color:black;}
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
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;
color:black;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:"Consolas",serif;
color:black;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@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]-->
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">>Can
you elaborate on this? What do you mean by figuring out
where the restrictions are needed?<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Sure.
I’m just referring to having the front end support the
FENV_ACCESS pragma (or whatever else) to decide for whatever
scope it is translating whether or not it needs the
constrained intrinsics. I found one of the places in the
front end where it was emitting an fadd instruction, and I
wrote some code of the form ‘if (true) emit the intrinsic
instead’ to test out an end-to-end code path. So what’s
missing is a replacement of that ‘if (true)’ with something
that actually checks the compilation context to decide what
should happen.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">I
might have been exaggerating a bit when I described this as
‘much harder’ but generating the intrinsic is fairly
trivial.</span></p>
</div>
</blockquote>
<br>
I think that you should handle this in the same way that we handle
the FP_CONTRACT pragma. If you grep clang for fp_contract and
FPContractable you should see how this works.<br>
<br>
-Hal<br>
<br>
<blockquote
cite="mid:0983E6C011D2DC4188F8761B533492DE576FADB2@ORSMSX115.amr.corp.intel.com"
type="cite">
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">-Andy<o:p></o:p></span></p>
<p class="MsoNormal"><a moz-do-not-send="true"
name="_MailEndCompose"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></a></p>
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><a moz-do-not-send="true"
name="_____replyseparator"></a><b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">From:</span></b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">
Hal Finkel [<a class="moz-txt-link-freetext" href="mailto:hfinkel@anl.gov">mailto:hfinkel@anl.gov</a>]
<br>
<b>Sent:</b> Wednesday, March 15, 2017 1:55 PM<br>
<b>To:</b> Kaylor, Andrew
<a class="moz-txt-link-rfc2396E" href="mailto:andrew.kaylor@intel.com"><andrew.kaylor@intel.com></a>; Sanjay Patel
<a class="moz-txt-link-rfc2396E" href="mailto:spatel@rotateright.com"><spatel@rotateright.com></a>; Samuel Antão
<a class="moz-txt-link-rfc2396E" href="mailto:samuelfantao@gmail.com"><samuelfantao@gmail.com></a><br>
<b>Cc:</b> llvm-dev <a class="moz-txt-link-rfc2396E" href="mailto:llvm-dev@lists.llvm.org"><llvm-dev@lists.llvm.org></a>;
<a class="moz-txt-link-abbreviated" href="mailto:acjacob@us.ibm.com">acjacob@us.ibm.com</a><br>
<b>Subject:</b> Re: [llvm-dev] Speculative execution of
FP divide Instructions - Call-Graph Simplify<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p><o:p> </o:p></p>
<div>
<p class="MsoNormal">On 03/15/2017 01:35 PM, Kaylor, Andrew
via llvm-dev wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">It’s
true, I am working on this. I have committed the initial
patch to add constrained intrinsics for the basic FP
operations. This has the desired effect of preventing
optimizations that would violate strict FP semantics with
regard to rounding mode and exception status, but it also
prevents many safe optimizations. Later this year I’ll be
going through the code base and trying to teach various
optimizations to handle the constrained intrinsics safely.</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Nothing
has been added to clang yet to generate these intrinsics,
though I have some rough code to do so that’s just waiting
for an implementation of the much harder task of figuring
out when such restrictions are needed. </span><o:p></o:p></p>
</blockquote>
<p class="MsoNormal"><br>
Can you elaborate on this? What do you mean by figuring out
where the restrictions are needed?<br>
<br>
-Hal<br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">If
anyone did have a front end that generated these
intrinsics, everything is in place to get them through to
code generation (though they currently become at least
theoretically unrestricted again after ISel). I have an
experimental pass that converts all basic FP operations to
the constrained versions and I’ve been able to
successfully compile and run real-world FP-using
applications with that pass in place.</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">I’m
currently working on a patch to add constrained versions
of the standard library FP intrinsics (sin, cos, pow,
etc.).</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">If
anyone is interested in getting pieces of the
work-in-progress I’ve mentioned above to test drive, let
me know. I’d be happy to share.</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">-Andy</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></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">
Sanjay Patel [<a moz-do-not-send="true"
href="mailto:spatel@rotateright.com">mailto:spatel@rotateright.com</a>]
<br>
<b>Sent:</b> Wednesday, March 15, 2017 8:16 AM<br>
<b>To:</b> Samuel Antão <a moz-do-not-send="true"
href="mailto:samuelfantao@gmail.com"><samuelfantao@gmail.com></a>;
Kaylor, Andrew
<a moz-do-not-send="true"
href="mailto:andrew.kaylor@intel.com"><andrew.kaylor@intel.com></a><br>
<b>Cc:</b> llvm-dev <a moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org"><llvm-dev@lists.llvm.org></a>;
<a moz-do-not-send="true" href="mailto:acjacob@us.ibm.com">acjacob@us.ibm.com</a><br>
<b>Subject:</b> Re: [llvm-dev] Speculative execution of FP
divide Instructions - Call-Graph Simplify</span><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.5pt">>
- is there any target for which fp division does not
have side effects?
</span><o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
Yes - all of them. This goes back to the fact that
clang/llvm do not support changing the FPENV:<br>
<a moz-do-not-send="true"
href="https://bugs.llvm.org/show_bug.cgi?id=8100"
target="_blank">https://bugs.llvm.org/show_bug.cgi?id=8100</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">There
has been some effort to change that recently, so maybe
this is (partly) fixed? (cc'ing Andy Kaylor)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">These reports may also provide info /
answers / work-arounds:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><a moz-do-not-send="true"
href="https://bugs.llvm.org/show_bug.cgi?id=6050"
target="_blank">https://bugs.llvm.org/show_bug.cgi?id=6050</a><br>
<a moz-do-not-send="true"
href="https://bugs.llvm.org/show_bug.cgi?id=24343">https://bugs.llvm.org/show_bug.cgi?id=24343</a><o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><a moz-do-not-send="true"
href="https://bugs.llvm.org/show_bug.cgi?id=24818"
target="_blank">https://bugs.llvm.org/show_bug.cgi?id=24818</a><o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"> <o:p></o:p></p>
<div>
<p class="MsoNormal">On Wed, Mar 15, 2017 at 3:41
AM, Samuel Antão via llvm-dev <<a
moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org"
target="_blank">llvm-dev@lists.llvm.org</a>>
wrote:<o:p></o:p></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:9.5pt">Hi all,</span><o:p></o:p></p>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt">I came across an
issue caused by the Call-Graph Simplify
Pass. Here is a a small repro:</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt">```</span><o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt">define double
@foo(double %a1, double %a2, double
%a3) #0 {</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt">entry:</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt"> %a_mul =
fmul double %a1, %a2</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt"> %a_cmp =
fcmp ogt double %a3, %a_mul</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt"> br i1
%a_cmp, label %a.then, label %a.end</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt">a.then:
</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt"> %a_div =
fdiv double %a_mul, %a3</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt"> br label
%a.end</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt">a.end:</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt"> %a_factor =
phi double [ %a_div, %a.then ], [
1.000000e+00, %entry ]</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt"> ret double
%a_factor</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt">}</span><o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt">```</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt">Here, the
conditional is guarding a possible
division by zero. However if I run
CGSimplify on this I get:</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt">```</span><o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt">define double
@foo(double %a1, double %a2, double
%a3) local_unnamed_addr #0 {</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt">entry:</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt"> %a_mul =
fmul double %a1, %a2</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt"> %a_cmp =
fcmp olt double %a_mul, %a3</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt"> %a_div =
fdiv double %a_mul, %a3</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt"> %a_factor =
select i1 %a_cmp, double %a_div,
double 1.000000e+00</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt"> ret double
%a_factor</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt">}</span><o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt">``` </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt">This will cause
a FP arithmetic exception, and the
application will get a SIGFPE signal.
The code that drives the change in the
optimizer relies on
`llvm::isSafeToSpeculativelyExecute` to
decide whether the division should be
performed speculatively. Right now, this
function returns true. One could do
something similar to integer divisions
and add a case there (this solved the
issue for me):</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt">```</span><o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt">diff --git
a/lib/Analysis/ValueTracking.cpp
b/lib/Analysis/ValueTracking.cpp</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt">index
1761dac..c61fefd 100644</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt">---
a/lib/Analysis/ValueTracking.cpp</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt">+++
b/lib/Analysis/ValueTracking.cpp</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt">@@ -3352,6
+3352,21 @@ bool
llvm::isSafeToSpeculativelyExecute(const
Value *V,</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt"> // The
numerator *might* be MinSignedValue.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt"> return
false;</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt"> }</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt">+ case
Instruction::FDiv:</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt">+ case
Instruction::FRem:{</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt">+ const
Value *Denominator =
Inst->getOperand(1);</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt">+ // x / y
is undefined if y == 0</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt">+ // The
denominator is not a constant, so
there is nothing we can do to prove</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt">+ // it is
non-zero.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt">+ if (auto
*VV =
dyn_cast<ConstantVector>(Denominator))</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt">+
Denominator = VV->getSplatValue();</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt">+ if
(!isa<ConstantFP>(Denominator))</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt">+ return
false;</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt">+ // The
denominator is a zero constant - we
can't speculate here.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt">+ if
(m_AnyZero().match(Denominator))</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt">+ return
false;</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt">+ return
true;</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt">+ }</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt"> case
Instruction::Load: {</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt"> const
LoadInst *LI =
cast<LoadInst>(Inst);</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt"> if
(!LI->isUnordered() ||</span><o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt">```</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt">I did my tests
using a powerpc64le target, but I
couldn't find any target specific login
involved in this transform. In any case,
I wanted to drop the questions: </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt">- is there any
target that would benefit from
speculative fp divisions? </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt">- is there any
target for which fp division does not
have side effects? </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt">If not, I can go
ahead and post the patch above for
review.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt">Many thanks!</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.5pt">Sam</span><o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org"
target="_blank">llvm-dev@lists.llvm.org</a><br>
<a moz-do-not-send="true"
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><br>
<br>
<br>
<o:p></o:p></p>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>LLVM Developers mailing list<o:p></o:p></pre>
<pre><a moz-do-not-send="true" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><o:p></o:p></pre>
<pre><a moz-do-not-send="true" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><o:p></o:p></pre>
</blockquote>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<pre>-- <o:p></o:p></pre>
<pre>Hal Finkel<o:p></o:p></pre>
<pre>Lead, Compiler Technology and Programming Languages<o:p></o:p></pre>
<pre>Leadership Computing Facility<o:p></o:p></pre>
<pre>Argonne National Laboratory<o:p></o:p></pre>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>