<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Sorry for the delayed response. <br>
</p>
<div class="moz-cite-prefix">On 08/23/2018 10:01 AM, John Brawn
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:DB7PR08MB32738EF94DD53649032179B38E370@DB7PR08MB3273.eurprd08.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 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:0cm;
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:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
color:black;}
span.EmailStyle20
{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:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:939336499;
mso-list-template-ids:845055970;}
@list l0:level1
{mso-level-start-at:2;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1
{mso-list-id:1636136645;
mso-list-template-ids:845055970;}
@list l1:level1
{mso-level-start-at:2;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l2
{mso-list-id:1949267029;
mso-list-template-ids:845055970;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></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">> Here's another motivating bug where
early transform to select prevents optimization:<o:p></o:p></p>
<p class="MsoNormal">> <a
href="https://bugs.llvm.org/show_bug.cgi?id=36760"
moz-do-not-send="true">https://bugs.llvm.org/show_bug.cgi?id=36760</a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">> Is that case affected by this patch?<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">From
a quick reading of that bug it looks like CVP needs to be
enhanced to do a certain transformation, but the presence<br>
of a select means that even with that enhancement it wouldn’t
do anything. With this patch we have a phi and so I think<br>
that if the CVP enhancement were done it should work.<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">>>>
1. LICM does not know how to hoist or sink regions. It does
know how to hoist and sink selects.<br>
>>I think we should teach LICM to do this eventually.<br>
>Agreed. I just don't currently see patches to do so.
Once LICM supports region hoisting, much of my concern
disappears.<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I’ve
looked into what happens with LICM with this change, and it
looks like everything except the phi gets hoisted, then<br>
later the phi is turned into a select, then a later LICM pass
hoists the select. For the very simple tests I tried we end up
with<br>
the same result in the end, but I wouldn’t be surprised if
indeed LICM not doing this makes things worse in more complex<br>
cases.<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I’ve
hacked together a modification to LICM to make it able to
hoist phis (by essentially hoisting entire blocks instead of<br>
moving everything into a single preheader block) and it seemed
to work OK, so I’ll get to work on getting that working<br>
properly and committed before I touch phi-to-select
transformation.</p>
</div>
</blockquote>
This would be a really useful extension to LICM. I look forward to
the patch. I was half considering an approach recently where LICM
itself did phi-to-select if all of the operands to the resulting phi
would be loop invariant. It was just ugly enough I didn't move
forward with it, but we have seen cases where it would resolve pass
ordering problems leading to strictly better results overall. I
suspect your region hoister would have the same overall effect. <br>
<br>
<blockquote type="cite"
cite="mid:DB7PR08MB32738EF94DD53649032179B38E370@DB7PR08MB3273.eurprd08.prod.outlook.com">
<div class="WordSection1">
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">>
InstCombine has limited support for triangles/diamonds, but
fairly extensive support for selects.<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Currently
I have InstCombine running directly after phis have been
turned into selects, so this should only be a problem if<br>
something before that relies on the select instcombine having
already happened. I’ll look into that to see if it is indeed a<br>
problem.<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">>>>EarlyCSE
and GVN do not know how to eliminate fully redundant
triangles/diamonds. PRE *may* get some of these cases, but
that is by no means guaranteed or likely to be robust.<br>
>>Agreed, we’ll need a plan to deal with these issues.<br>
>Again, I'd love to see these issues fixed. Once that's
done, the convert about phi vs select as canonical form is
much less relevant. <o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I’ll
look into this.<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">>
For the one of the specific cases mentioned, teaching GVN to
do FRE and PRE for loads from selects of pointers just doesn't
seem that painful. I would be really tempted to do that<br>
> instead. Similarly, walking facts back from select uses
in CVP seems generally useful since we have use dependent
facts in a bunch of contexts, not just selects. (Call
arguments for
<br>
> instance, non-null from unconditional deref, etc..)<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Actually
making GVN able to handle selects being painful is exactly the
reason I’m proposing doing this. GVN has a hard<br>
constraint that a single block can only have a single
available value, and attempting to change that (which you have
to do<br>
when selecting between values defined in the same block)
causes a ton of problems that have to be resolved.<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">John<o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm
0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext"
lang="EN-US">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext"
lang="EN-US"> Philip Reames
[<a class="moz-txt-link-freetext" href="mailto:listmail@philipreames.com">mailto:listmail@philipreames.com</a>]
<br>
<b>Sent:</b> 17 August 2018 21:17<br>
<b>To:</b> Amara Emerson; Hal Finkel; John Brawn<br>
<b>Cc:</b> Sanjay Patel; <a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>; nd<br>
<b>Subject:</b> Re: [llvm-dev] [RFC] Delaying
phi-to-select transformation until later in the pass
pipeline<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On 08/17/2018 09:02 AM, Amara Emerson
wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On Aug 15, 2018, at 10:57 PM, Hal
Finkel via llvm-dev <<a
href="mailto:llvm-dev@lists.llvm.org"
moz-do-not-send="true">llvm-dev@lists.llvm.org</a>>
wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On 08/15/2018 02:38 PM,
Philip Reames via llvm-dev wrote:<o:p></o:p></p>
</div>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I'm
concerned that we're focusing on one side of
this. Let me point out a few concerns
w/changing the canonical form here:<o:p></o:p></p>
<ol start="1" type="1">
<li class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l2
level1 lfo1">
LICM does not know how to hoist or sink
regions. It does know how to hoist and sink
selects.<o:p></o:p></li>
</ol>
</blockquote>
</div>
</div>
</blockquote>
<p class="MsoNormal">I think we should teach LICM to do
this eventually.<o:p></o:p></p>
</div>
</blockquote>
<p class="MsoNormal">Agreed. I just don't currently see
patches to do so. Once LICM supports region hoisting, much
of my concern disappears.<br>
<br>
<o:p></o:p></p>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<ol start="2" type="1">
<li class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0
level1 lfo2">
InstCombine has limited support for
triangles/diamonds, but fairly extensive support
for selects.<o:p></o:p></li>
<li class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0
level1 lfo2">
EarlyCSE and GVN do not know how to eliminate
fully redundant triangles/diamonds. PRE *may*
get some of these cases, but that is by no means
guaranteed or likely to be robust.<o:p></o:p></li>
</ol>
</blockquote>
</div>
</div>
</blockquote>
<p class="MsoNormal">Agreed, we’ll need a plan to deal with
these issues.<o:p></o:p></p>
</div>
<p class="MsoNormal">Again, I'd love to see these issues
fixed. Once that's done, the convert about phi vs select as
canonical form is much less relevant.
<br>
<br>
<o:p></o:p></p>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">My
personal opinion is that selects are the
appropriate canonical form. <o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">For
the one of the specific cases mentioned, teaching
GVN to do FRE and PRE for loads from selects of
pointers just doesn't seem that painful. I would
be really tempted to do that instead. Similarly,
walking facts back from select uses in CVP seems
generally useful since we have use dependent facts
in a bunch of contexts, not just selects. (Call
arguments for instance, non-null from
unconditional deref, etc..)<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">To
be clear, I am raising concerns, not actively
objecting to this. If you want to move forward
and commit to work through all of the issues
identified I wont actively stand in the way.<o:p></o:p></p>
</blockquote>
<p class="MsoNormal"><br>
As I've expressed in the past, I think that not
using select as part of our canonical form is
potentially a superior design. However, it would be
a major change. In addition to the issues that
Philip mentions, there's also the fact that we'll
just have more basic blocks and that, in itself,
could lead to an increase in compile time. However,
working through these issues will likely leave us
with a more-robust optimizer.<br>
<br>
See also: <a
href="https://bugs.llvm.org/show_bug.cgi?id=34603#c19"
moz-do-not-send="true">https://bugs.llvm.org/show_bug.cgi?id=34603#c19</a><o:p></o:p></p>
</div>
</div>
</blockquote>
<p class="MsoNormal">Canonicalizing to phis is my preference
too.<br>
<br>
<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><br>
-Hal<br>
<br>
<br>
<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Philip<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On 08/14/2018 12:39 PM, Sanjay
Patel via llvm-dev wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal">I didn't look closely at the
new patch, but this appears to be a small
extension to:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><a
href="https://reviews.llvm.org/D38566"
moz-do-not-send="true">https://reviews.llvm.org/D38566</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">...and the GVN-based reasons
for delaying transformation to 'select' are
discussed in detail in the motivating bug for
that patch:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><a
href="https://bugs.llvm.org/show_bug.cgi?id=34603"
moz-do-not-send="true">https://bugs.llvm.org/show_bug.cgi?id=34603</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">So this sounds like the right
direction to me. Note that there was objection
to the implementation (a pile of pass options
vs. uniquely named passes).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Here's another motivating bug
where early transform to select prevents
optimization:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><a
href="https://bugs.llvm.org/show_bug.cgi?id=36760"
moz-do-not-send="true">https://bugs.llvm.org/show_bug.cgi?id=36760</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Is that case affected by this
patch?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Tue, Aug 14, 2018 at 11:17
AM, John Brawn via llvm-dev <<a
href="mailto:llvm-dev@lists.llvm.org"
target="_blank" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>>
wrote:<o:p></o:p></p>
<p class="MsoNormal">Summary<br>
=======<br>
<br>
I'm planning on adjusting SimplifyCFG so that it
doesn't turn two-entry phi<br>
nodes into selects until later in the pass
pipeline, to give passes which can<br>
understand phis but not selects more opportunity
to optimize. The thing I'm<br>
trying to do which made me think of doing this
is described below, but from the<br>
benchmarking I've done it looks like this is
overall a good idea regardless of<br>
if I manage to get that done or not.<br>
<br>
Motivation<br>
==========<br>
<br>
My goal is to get clang to optimize some code
containing a call to<br>
std::min_element which is dereferenced, so
something like:<br>
<br>
float min_element_example(float *data, int
size)<br>
{<br>
return *std::min_element(data, data+size);<br>
}<br>
<br>
which, after inlining a specialization, looks
like:<br>
<br>
float min_element_example_inlined(float
*first, float *last)<br>
{<br>
for (float *p = first; p != last; ++p)<br>
{<br>
if (*p < *first)<br>
first = p;<br>
}<br>
return *first;<br>
}<br>
<br>
There are two loads in the loop, *p and *first,
but actually the load *p can be<br>
eliminated by using either the previous load *p
or the previous *first,<br>
depending on if the if-condition was taken or
not. However the<br>
"if (*p < *first) first = p" gets turned by
simplifycfg into a select and this<br>
makes optimizing this a lot harder because you
no longer have distinct paths<br>
through the CFG.<br>
<br>
I have some ideas on how to do the optimization
(see my previous RFC "Making GVN<br>
able to visit the same block more than once"
posted in April, though I've<br>
decided that the specific idea presented there
isn't the right way to do it),<br>
but I think the first step is to make sure we
don't have a select when we try<br>
to optimise this.<br>
<br>
Approach<br>
========<br>
<br>
I've posted a patch to <a
href="https://reviews.llvm.org/D50723"
target="_blank" moz-do-not-send="true">
https://reviews.llvm.org/D50723</a> showing
what I'm<br>
intending to do. An extra parameter is added to
SimplifyCFG to control whether<br>
two-entry phi nodes are converted into select,
and this is set to false in all<br>
instances before the end of module
simplification. At the end of module<br>
simplification we do SimplifyCFG, then
Instcombine to optimise the selects that<br>
are introduced, then EarlyCSE to eliminate
common subexpressions introduced by<br>
instcombine.<o:p></o:p></p>
</div>
</div>
</blockquote>
</div>
</div>
<p class="MsoNormal">Is scheduling another simplifycfg,
instcombine + earlycse pass really necessary? I’m
concerned about the compile time impact.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Cheers,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Amara<br>
<br>
<o:p></o:p></p>
<div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<blockquote style="border:none;border-left:solid
#CCCCCC 1.0pt;padding:0cm 0cm 0cm
6.0pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal"><br>
Benchmark Results<br>
=================<br>
<br>
These are performance differences reported
by LNT when running llvm-test-suite,<br>
spec2000, and spec2006 at -O3 with and
without the patch linked above (using<br>
trunk llvm from a week or so ago).<br>
<br>
AArch64 results on ARM Cortex-A72:<br>
<br>
Performance Regressions - execution_time
Change<br>
SingleSource/Benchmarks/Shootout/Shootout-ary3
9.48%<br>
MultiSource/Benchmarks/TSVC/Packing-flt/Packing-flt
3.79%<br>
SingleSource/Benchmarks/CoyoteBench/huffbench
1.40%<br>
<br>
Performance Improvements - execution_time
Change<br>
MultiSource/Benchmarks/TSVC/Searching-dbl/Searching-dbl
-23.74%<br>
External/SPEC/CINT2000/256.bzip2/256.bzip2
-9.82%<br>
MultiSource/Benchmarks/TSVC/Searching-flt/Searching-flt
-9.57%<br>
MultiSource/Benchmarks/TSVC/Equivalencing-flt/Equivalencing-flt
-4.38%<br>
MultiSource/Benchmarks/TSVC/LinearDependence-flt/LinearDependence-flt
-3.94%<br>
MultiSource/Benchmarks/TSVC/Packing-dbl/Packing-dbl
-3.44%<br>
External/SPEC/CFP2006/453.povray/453.povray
-2.50%<br>
SingleSource/Benchmarks/Adobe-C++/stepanov_vector
-1.49%<br>
<br>
X86_64 results on Intel Xeon E5-2690:<br>
<br>
Performance Regressions - execution_time
Change<br>
MultiSource/Benchmarks/Ptrdist/yacr2/yacr2
5.62%<br>
<br>
Performance Improvements - execution_time
Change<br>
SingleSource/Benchmarks/Misc-C++/Large/sphereflake -4.43%<br>
External/SPEC/CINT2006/456.hmmer/456.hmmer
-2.50%<br>
External/SPEC/CINT2006/464.h264ref/464.h264ref -1.60%<br>
MultiSource/Benchmarks/nbench/nbench
-1.19%<br>
SingleSource/Benchmarks/Adobe-C++/functionobjects -1.07%<br>
<br>
I had a brief look at the regressions and
they all look to be caused by<br>
getting bad luck with branch mispredictions:
I looked into the Shootout-ary3 and<br>
yacr2 cases and in both the hot code path
was the same with and without the<br>
patch, but with more mispredictions probably
caused by changes elsewhere.<br>
<br>
John<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org"
moz-do-not-send="true">llvm-dev@lists.llvm.org</a><br>
<a
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
target="_blank" moz-do-not-send="true">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>
<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 href="mailto:llvm-dev@lists.llvm.org" moz-do-not-send="true">llvm-dev@lists.llvm.org</a><o:p></o:p></pre>
<pre><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" moz-do-not-send="true">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><o:p></o:p></pre>
</blockquote>
<p class="MsoNormal"><br>
<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 href="mailto:llvm-dev@lists.llvm.org" moz-do-not-send="true">llvm-dev@lists.llvm.org</a><o:p></o:p></pre>
<pre><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" moz-do-not-send="true">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>
<p class="MsoNormal">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org"
moz-do-not-send="true">llvm-dev@lists.llvm.org</a><br>
<a
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
moz-do-not-send="true">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</blockquote>
<br>
</body>
</html>