<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>(resend a bounced message). </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><div class="h5"><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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote><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><span style="color:rgb(34,34,34)"></span></div></div></div></div></div></div></blockquote><div> </div><div>Do not under estimate the importance of build system integration. Tools 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><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"><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_quote"><div>and I think more traditional LTO schemes with LLVM have just used bitcode/IR output as an input to the LTO link step. I think what we're talking about here is the best way to encode the data that thin lto needs/wants in order to handle summary information etc right?</div></div></div></blockquote><div></div></span></div></div></div></blockquote><div> </div><div><br></div><div>Not entirely. We want both functionality and usability. Easy integration with build is considered as the usability.  Asking users to use wrapper tools in order to pass plugin path is not something I consider as being highly usable -- but I can be convinced the other way :)</div><div><br></div><div>David</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"><br></div></div>
</blockquote></div><br></div></div>