<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 7/17/13 4:12 PM, Nick Kledzik wrote:<br>
</div>
<blockquote
cite="mid:DB2C45E0-90D3-4C23-9D60-68C94375A52F@apple.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
On Jul 14, 2013, at 7:07 PM, Andrew Trick <<a
moz-do-not-send="true" href="mailto:atrick@apple.com">atrick@apple.com</a>>
wrote:<br>
<div>
<blockquote type="cite">
<div style="font-family: Helvetica; font-size: 12px;
font-style: normal; font-variant: normal; font-weight:
normal; letter-spacing: normal; line-height: normal;
orphans: auto; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; widows: auto;
word-spacing: 0px; -webkit-text-stroke-width: 0px;">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.</div>
</blockquote>
<div dir="auto">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. </div>
<div dir="auto"><br>
</div>
</div>
</blockquote>
We can view partitioning as a "transformation". Unless the
transformation is absolutely no-op, <br>
it will change something. If we care the consistency in binaries,
we either consistently use partition <br>
or consistently not use partition. <br>
<br>
<blockquote
cite="mid:DB2C45E0-90D3-4C23-9D60-68C94375A52F@apple.com"
type="cite">
<div><br>
</div>
<div>
<blockquote type="cite"> 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.<br>
</blockquote>
</div>
<div>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?</div>
</blockquote>
<br>
We could append the object files as an alternative. <br>
However, how do we know the /path/to/ld from the existing interface
ABIs? <br>
How do we know the flags feed to the ld (more often than not, "-r"
alone is enough, <br>
but some linkers may need more).<br>
<br>
In my rudimentary implement, I hack by hardcoding to /usr/bin/ld.<br>
<br>
I think adding object one by one back to the linker is better as the
linker already have <br>
enough information. <br>
</body>
</html>