<p dir="ltr"><br>
><br>
> Quick question: Is the word required to support ThinLTO using llvm's native tools orthogonal to that required to supporting non-llvm tools?  If not, would it make sense to start with a deployment of entirely LLVM based tools - since there seems to be general interest in that - and then come back to the non-llvm based tools separately?<br>
><br>
> Personally, I see both sides here.  I can understand why you want to minimize build configuration changes - they tend to be painful - but I also am reluctant to design a major enhancement to LLVM under the assumption that LLVM's own tools aren't adequate for the purpose. That seems like it would be majorly problematic from the perspective of the project as a whole.<br>
><br>
> (I realize that LLVM's tools could simply extract the bitcode out of the wrapper file, but that seems unnecessarily complex for an *initial* LLVM only solution.)<br>
></p>
<p dir="ltr">Really late on this thread,  but I wanted to second Philip's position: wrapped bitcode can be interesting and we should consider it, but a bitcode only solution should probably come first.</p>
<p dir="ltr">The things thin lto seems to need are generally desirable bitcode features: easy to read symbol table, ability to read a single function, etc.</p>
<p dir="ltr">Cheers, <br>
Rafael <br>
</p>