<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: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=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@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:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}
/* 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;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.EmailStyle18
{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 90.0pt 72.0pt 90.0pt;}
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]-->
</head>
<body lang="ZH-CN" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<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""> llvmdev-bounces@cs.uiuc.edu [mailto:llvmdev-bounces@cs.uiuc.edu]
<b>On Behalf Of </b>Nick Kledzik<br>
<b>Sent:</b> Thursday, July 18, 2013 7:54 AM<br>
<b>To:</b> Shuxin Yang<br>
<b>Cc:</b> LLVM Developers Mailing List<br>
<b>Subject:</b> Re: [LLVMdev] [Proposal] Parallelize post-IPO stage.<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US">On Jul 17, 2013, at 4:29 PM, Shuxin Yang <<a href="mailto:shuxin.llvm@gmail.com">shuxin.llvm@gmail.com</a>> wrote:<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US"><br>
<br>
<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">On 7/17/13 4:12 PM, Nick Kledzik wrote:<o:p></o:p></span></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt;orphans: auto;text-align:start;widows: auto;-webkit-text-stroke-width: 0px;word-spacing:0px">
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">On Jul 14, 2013, at 7:07 PM, Andrew Trick <<a href="mailto:atrick@apple.com">atrick@apple.com</a>> wrote:<o:p></o:p></span></p>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">The partitioning should be deterministic. It’s just that the linker output now depends on the partitioning heuristics. As long that decision is based on the
input (not the host system), then it still meets Eric’s requirements. I just think it’s unfortunate that post-IPO partitioning (or more generally, parallel codegen) affects the output, but may be hard to avoid. It would be nice to be able to tune the partitioning
for compile time without worrying about code quality.<o:p></o:p></span></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">I also want to chime in on the importance of stable binary outputs. And not just same compiler and same sources produces same binary, but that minor changes
to either should cause minor changes to the output binary. For software updates, Apple updater tries to download only the delta to the binaries, so we want those to be as small as possible. In addition, it often happens late in an OS release cycle that
some critical bug is found and the fix is in the compiler. To qualify it, we rebuild the whole OS with the new compiler, then compare all the binaries in the OS, making sure only things related to the bug are changed. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><o:p> </o:p></span></p>
</div>
</div>
</blockquote>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica","sans-serif";background:white">We can view partitioning as a "transformation". Unless the transformation is absolutely no-op,<span class="apple-converted-space"> </span></span><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><br>
<span style="background:white">it will change something. If we care the consistency in binaries, we either consistently use partition<span class="apple-converted-space"> </span></span><br>
<span style="background:white">or consistently not use partition.<span class="apple-converted-space"> </span></span></span><span lang="EN-US"><o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US">But doesn’t "<span style="background:white">consistently not use partition” mean “don’t use the optimization you are working on”? Isn’t there someone to get the same output no matter how it is partitioned? </span><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US"><br>
<br>
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><br style="orphans: auto;text-align:start;widows: auto;-webkit-text-stroke-width: 0px;word-spacing:0px">
<br>
</span><span lang="EN-US"><o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><o:p> </o:p></span></p>
</div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica","sans-serif""> The compiler used to generate a single object file from the merged<br>
IR, now it will generate multiple of them, one for each partition.<o:p></o:p></span></p>
</blockquote>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">I have not studied the MC interface, but why does each partition need to generate a separate object file? Why can’t the first partition done create an object
file, and as other partitions finish, they just append to that object file?<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><br>
<span style="background:white">We could append the object files as an alternative.<span class="apple-converted-space"> </span></span><br>
<span style="background:white">However, how do we know the /path/to/ld from the existing interface ABIs?<span class="apple-converted-space"> </span></span><br>
<span style="background:white">How do we know the flags feed to the ld (more often than not, "-r" alone is enough, <span class="apple-converted-space"> </span></span><br>
<span style="background:white">but some linkers may need more).</span><br>
<br>
<span style="background:white">In my rudimentary implement, I hack by hardcoding to /usr/bin/ld.</span><br>
<br>
<span style="background:white">I think adding object one by one back to the linker is better as the linker already have<span class="apple-converted-space"> </span></span><br>
<span style="background:white">enough information.<span class="apple-converted-space"> </span></span></span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">I think you missed my point, or you are really thinking from the multi-process point of view. In LLVM there is an MCWriter used to produce object files. Your model is that if there are three partitions, then there
will be three MCWriter objects, each producing an object file. What I am saying is to have only one MCWriter object and have all three partitions stream their content out through the one MCWriter, producing one object file.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">[Xiaofei] if you only target parallelizing post LTO passes, there is no need to partition, parallelizing function passes is enough and could achieve
better performance (no need to link partitions together since it share AsmPrinter & MCWriter)<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">-Nick<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
</div>
</body>
</html>