<div dir="ltr">On Mon, Aug 26, 2013 at 5:53 PM, Shuxin Yang <span dir="ltr"><<a href="mailto:shuxin.llvm@gmail.com" target="_blank" class="cremed">shuxin.llvm@gmail.com</a>></span> wrote:<br><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">We certainly need a way to feed multiple resulting objects back to linker. There are couple of ways<br>
for this end:<br>
<br>
1) 'ld -r all-resulting-obj-on-disk -o result.o" and feed the only object file (i.e. the result.o)<br>
back to linker<br>
<br>
2) keep the resulting objects in memory buffer, and feedback to buffers back to linker<br>
(as proposed by Nick)<br>
<br>
3) As with GNU gold, save the resulting objects on disk, and feed the these disk files back to linker<br>
one by one.<br>
<br>
I'm big linker nut. I don't know which way work better. I try to use 1) as a workaround for the time being<br>
before 2) is available. People at Apple disagree my engineering approach.<br>
<br>
From compiler's perspective,<br>
o. 1) is not just workaround, 3) is certainly better than 1).<br>
o. 2) will win if the program being compiled is small- or medium-sized.<br>
With huge programs, it will be difficult for compiler to decide when and how to "spill" some stuff<br>
from memory to disk. Folks in Apple iterate and reiterate we only consider the case that the entire<br>
program can be loaded in memory. So, the added difficulty for compiler dose not seems to be a<br>
problem for the workload we care about.</blockquote><div><br></div><div><div>Shuxin, I'm not sure what you're trying to accomplish here, but I don't think this is the right approach.</div><div><br></div>
<div>First, you seem to be pursuing a partitioning scheme for parallelizing LTO work despite *no* consensus that this is the correct approach in any of the community discussions I can find. Please don't commit code toward a design that the community has expressed serious reservations about without review.</div>
<div><br></div><div>Second, you are committing a new API to the set of the stable C APIs that libLTO exposes without a thorough discussion on the mailing list. It is possible I have missed this discussion, but I did look and failed to find anything that seems to resemble a review, much less an LGTM. If I have missed it, I apologize and please direct me at the thread. I bring this up because the specific interface seems surprising to me.</div>
<div><br></div><div>Third, you are justifying the particular approach with a deflection to some discussion within Apple or with those developers you work with at Apple. While this may in fact be the motivation for this patch, the open source community is often not party to these discussions. ;] It would help us if you would just give the specific basis rather than referencing a discussion that we weren't involved with. As it happens, I suspect I agree with these "Folks in Apple" that it is useful to specifically optimize for the case that an entire program fits into memory, bypassing the filesystem. However, there are many paths to that end result. From the little information in the commit log there isn't really enough to tell why *this* is the necessary path forward (in fact, I'm somewhat confident it isn't).</div>
</div><div><br></div><div><br></div><div>So, to get back to Eric's original question: what is the motivation for this API, it's expected actual usage, and the reason why it is important to stub out in this way now? Better yet, could we have that discussion before growing the set of stable APIs that we claim to never regress?</div>
<div><br></div><div>-Chandler</div></div></div></div>