<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<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:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
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.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.m6338550611856304782hoenzb
{mso-style-name:m_6338550611856304782hoenzb;}
span.m6338550611856304782m9203321602662809102gmail-m-6862847086955145534hoenzb
{mso-style-name:m_6338550611856304782m_9203321602662809102gmail-m_-6862847086955145534hoenzb;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
@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:939798225;
mso-list-type:hybrid;
mso-list-template-ids:902736458 134807553 134807555 134807557 134807553 134807555 134807557 134807553 134807555 134807557;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
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]-->
</head>
<body lang="EN-GB" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Hi Rui,</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’ll try to answer your specific question on ownership of the MIPS ABIs and also recap some of the important ABI changes or proposals that have happened, some
of which others have already pointed at.</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 we go with the last person who touched it owns it stance then I think I would own the MIPS ABIs under that policy! The real position is that nobody to my
knowledge claims to own the MIPS ABI and I believe that applies to most architectures as well. As architecture owners, Imagination’s engineers are still only one of the many stakeholders in the ABI and generally we look to the largest user base to hold the
golden reference for the ABI. For MIPS this is upstream binutils BFD linker and glibc and I would generally expect these to be the places to debate and discuss ABI changes as the level of compatibility and correctness these projects aim for is extremely high.
</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">A quick summary of recent and proposed ABI changes for MIPS (I can get links to mail archives to all of these if necessary but have not included them right
now):</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="MsoListParagraph" style="text-indent:-18.0pt;mso-list:l0 level1 lfo1"><![if !supportLists]><span style="font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Introduction of 64-bit FPRs in o32. This took over 12 months to design, agree and commit to the initial repos of binutils and glibc with many more
months before seeding the remaining c libraries, linkers and other affected tools. It is pretty much true that this was the first major change to the MIPS ABIs in several years but having done the work it is easy to see why! I knew an ABI change was hard but
this was more work than I could have ever expected. The effort was invested as it was an essential ABI change to support new architectural features, if it had been a nice-to-have it would not have been worth the effort. Incidentally this feature had been a
nice-to-have, but not essential, for at about 10 years prior to me implementing it.</span><o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt;mso-list:l0 level1 lfo1"><![if !supportLists]><span style="font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">PIE shared library debug – DT_MIPS_RLD_MAP_REL. This is an extension required to support finding the shared libraries used by a PIE because MIPS unique
DT_MIPS_RLD_MAP would not work with PIE. During this design the community concluded that while the original solution obviously needed fixing the underlying achievement of keeping the dynamic section read-only at runtime was a worthy goal and the solution retained
that (potentially unique) MIPS benefit.</span><o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt;mso-list:l0 level1 lfo1"><![if !supportLists]><span style="font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">ifunc – This is still in review and has slowed down a bit in pace. The general issues of how it will work with the GOT have been resolved and it should
progress.</span><o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt;mso-list:l0 level1 lfo1"><![if !supportLists]><span style="font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">PT_GNU_STACK – This is also still in development and is complex for MIPS because of the Linux kernel using the user-stack for execution of code during
some exception handling. This is a multi-component problem.</span><o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt;mso-list:l0 level1 lfo1"><![if !supportLists]><span style="font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">.gnu.hash – a solution to this has been proposed by an engineer from Cisco and is designed to work with the MIPS ABI nuances in a compatible way.
This is held up by copyright assignment issues as the code is implemented for binutils which requires FSF copyright assignment for inclusion.</span><o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt;mso-list:l0 level1 lfo1"><![if !supportLists]><span style="font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Recent discussions on the reducing the size of dynamic relocations for PIE are interesting because MIPS has a partial solution to this already due
to the implicitly relocated local section of the GOT which costs no executable space.</span><o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt;mso-list:l0 level1 lfo1"><![if !supportLists]><span style="font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Older issues that have been addressed include the addition of a static object model for n64 which was not originally designed to be non-PIC, addition
of PLTs for o32 and n32 and likely more that I can’t remember.</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">Also on a positive note, I‘m pleased to say that we have active maintenance on all of binutils LD, GOLD, and LLD which covers the major static linkers currently
so the potential for change is good. Your input here is really valuable and is a fantastic source of information to guide potential improvements; it is appreciated. The only challenge is finding either community contributors for the changes or business reasons
to invest in the change. We do a bit of both at Imagination but obviously on a case by case basis.</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 hope that is enough reassurance that MIPS ABIs are not forgotten, they are just incredibly complex and expensive to maintain and change.<o:p></o:p></span></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">Thanks,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Matthew</span><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>
<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 lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> llvm-commits [mailto:llvm-commits-bounces@lists.llvm.org]
<b>On Behalf Of </b>Sean Silva via llvm-commits<br>
<b>Sent:</b> 03 May 2017 18:48<br>
<b>To:</b> Rui Ueyama<br>
<b>Cc:</b> llvm-commits<br>
<b>Subject:</b> Re: [PATCH] D31528: [ELF][MIPS] Multi-GOT implementation<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On May 2, 2017 4:26 PM, "Rui Ueyama" <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> wrote:<o:p></o:p></p>
<div>
<div>
<div>
<div>
<p class="MsoNormal">On Sun, Apr 30, 2017 at 10:02 PM, Sean Silva <<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>> wrote:<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Wed, Apr 26, 2017 at 6:57 AM, Rui Ueyama via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>> wrote:<o:p></o:p></p>
<div>
<p class="MsoNormal">I think I disagree. As I wrote there are still a lot of unnecessary divergences from the other ELF standards in the MIPS ABI, and in a long run, I believe these issues should be addressed, even if it means we need more code in a (possibly
long) transition period.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I think we should first and foremost focus on making LLD a production MIPS linker for today's environment. For example, making LLD be /usr/bin/ld for FreeBSD on MIPS.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The ABI is a very cross-functional thing, involving kernel (x N OS's), dynamic linker/loader (x N libc's), static linker (x N static linkers), compiler (x N compilers), MC/assembler (x N assemblers), package management (x N distros), and
other components (and there is likely not a perfect mailing list where active maintainers of all affected components are reading, making the organizational complexity extremely large). The costs of such a transition could easily enter into the millions of
dollars of engineer time (including user time, as some things are likely to be incompatible). Speaking for myself as an LLD developer, I don't think it's appropriate for LLD developers to be making requests to change an ABI that we don't even implement at
production quality.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">It sounds like we're pretty close to supporting MIPS at production quality, so I think we should move forward with that. Once that is done, we can concretely evaluate what things we want to be changed. I don't think it's worth even starting
a discussion right now.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">My 2 cents: I suspect that once we do support MIPS at production quality, we'll look at all the MIPS-specific code in LLD and say "this is annoying, but not bad enough to be worth churning the world with a new ABI". (i.e., it's a "frog
in boiling water" situation, but the water is only at 35 degrees C and not rising at a significant rate)<o:p></o:p></p>
</div>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<div>
<p class="MsoNormal">I agree that we eventually have to check this in, but what I'm trying to do is to understand the situation and and ask why why MIPS ABI has not been updated so long. It seems MIPS ABI is very conservative while ABIs for other architectures
are not that much.<o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">What is an ABI that you would consider not as conservative? You make it sound like most ABI's change in backward-incompatible ways "frequently".<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">-- Sean Silva<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<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">
<div>
<div>
<div>
<div>
<p class="MsoNormal">I could imagine a few examples (lack of clear ownership of the ABI?) but no one really seem to answer my question.<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<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">
<div>
<p class="MsoNormal">I believe, for example, we can agree that the very odd middle-endian header should have been fixed like 10 years ago.<o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I think that 10 years ago it was probably clear that the middle-endian header was undesirable and annoying, but I don't think it's at all obvious that 10 years ago a transition should have been started in order to change it; the costs of
doing that are enormous and probably not worth it. We would probably be stuck in a situation like .ctors/.dtors vs .init_array/.fini_array -- 10+ years later, we still have to support both, with no indication that we will ever be able to delete support for
one of them (like the xkcd comic that Joerg posted).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I think you would agree that making a new MIPS ABI just to end up in a situation like .{c,d}tors/.{init,fini}_array would just make things worse for us. What makes you so sure that that isn't going to happen? Is it worth the risk?<o:p></o:p></p>
</div>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<div>
<p class="MsoNormal">That is a valid concern and should be answered by people from the MIPS community. To me, it seems they should make a change to their ABI at least for the .gnu.hash section.<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="color:#888888">-- Sean Silva<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#888888"> <o:p></o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<div>
<p class="MsoNormal">I understand that it is of course not your fault. Who is maintaining the MIPS ABI?<o:p></o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Wed, Apr 26, 2017 at 3:17 AM, Simon Atanasyan <<a href="mailto:simon@atanasyan.com" target="_blank">simon@atanasyan.com</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal">I do not think that hypothetical MIPS ABI will be _much_ _more_<br>
similar to other ABIs. For example, as to me I would keep MIPS GOT<br>
almost the same because it's efficient and works well. Even if a<br>
dynamic linker starts to recognize multi-GOT, that removes only a few<br>
lines of code from LLD. And during a long transition period we will<br>
have to support both variants. Special rules for .dynsym ordering and<br>
unsupported --hash-style=gnu are tightly related to MIPS GOT. There is<br>
an oddity in calculation addends for "paired" relocations (R_MIPS_HI16<br>
/ R_MIPS_LO16) but we can consider this issue as fixed in N32 and N64<br>
ABI. Special sections like .reginfo, .MIPS.options, and .MIPS.abiflags<br>
are required to describe varieties of MIPS hardware. It's possible to<br>
rename default entry symbol s/__start/_start/, but it will not make<br>
LLD code much cleaner.<br>
<br>
In general, requirement to remove incompatibilities from MIPS ABI<br>
looks like a requirement to make MIPS ISA more similar to say X86 ISA<br>
for simplification of LLVM MC library code base. MIPS requires new ABI<br>
and finally I think it gets the new ABI, but I do not expect that this<br>
makes LLD code base smaller and cleaner.<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
On Tue, Apr 25, 2017 at 7:37 PM, Rui Ueyama via llvm-commits<br>
<<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>> wrote:<br>
> Simon, can you start a discussion in the MIPS ABI mailing list (if exists)<br>
> that you are getting a push-back due to the incompatibilities from other ELF<br>
> standards?<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><span class="m6338550611856304782m9203321602662809102gmail-m-6862847086955145534hoenzb"><span style="color:#888888">--</span></span><span style="color:#888888"><br>
<span class="m6338550611856304782m9203321602662809102gmail-m-6862847086955145534hoenzb">Simon Atanasyan</span></span><o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt">_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</blockquote>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>