<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 15, 2015 at 1:14 PM, Eric Christopher <span dir="ltr"><<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span><div><br></div></span><div>I don't think that natively wrapped bitcode gets you as much as you think it does anyhow, unless you're duplicating a lot of information (ar, as discussed earlier, aside). I'm not too worried about the build system as far as a wrapping mechanism </div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Do not under estimate the importance of build system integration. Tools </div></div></div></div></blockquote><div><br></div></span><div>I'm pretty sure I'm never going to underestimate build system integration. :)</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>used in the build can include ar, nm, ranlib, objcopy, strip, etc. The latest binutils  support plugin for ar, nm and ranlib, but not others.   objcopy can actually change visibility of symbols. It is conceivably easy to support this with native object wrapper (i.e. propagate the visibility change at IR reading time), but it is unclear wether existing plugin interfaces are enough for it.</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div></div></div></div></blockquote><div><br></div></span><div>Others have replied to this in more detail, but I'd like to understand more the compilation tools pipeline you're talking about </div></div></div></blockquote><div><br></div><div><br></div><div>This is just an example I have seen from a highly curated build system. </div><div><br></div><div>The engineering solution to be taken depends on the final goal and target users. If we are only targeting thinLTO for a small set of users who does have good handle on their build systems, it might be a different decision.  ThinLTO has the goal to be a drop-in replacement for O2 (basically enabling CMO everywhere), the requirement will be quite different. Making it harder to use won't help that goal. This basically means we need to cut down the dependency on plugins -- which can be controlled under an option. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>here where you need this particular functionality. Also, the engineering tradeoffs in looking at the plugin interfaces rather than this. </div><span class="HOEnZb"><font color="#888888"><div></div></font></span></div></div></blockquote><div><br></div><div>With native object wrapper, we almost get it (the objcopy example) for free. Symbol attributes can be changed in the final link step, so the combined index/summary will contain it and be used in backend compilation anyway.</div><div><br></div><div>thanks,</div><div><br></div><div>David</div><div> </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span class="HOEnZb"><font color="#888888"><div> </div></font></span></div></div></blockquote><div><br></div><div> </div></div><br></div></div>