Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
@nnethercote asked me to write up a more detailed plan for getting rid of LLVM bitcode in RLIBs, so here goes:
The proposed solution is to follow Clang's model: When compiling for cross-crate
The consequences of this approach are:
Steps to get there
That actually depends on how we resolve the open questions above.
Thanks for writing this up @michaelwoerister! This all sounds spot on to me, and my thoughts on the open questions would be:
I think we have a lot of liberties here to do whatever change we want. It's basically an implementation detail that compressed bitcode is in each rlib, so we basically need to ensure that use cases today continue to work tomorrow. Once we do that I think it's reasonably for us to both switch the defaults and to completely remove all support for compressed llvm bitcode.
One unfortunate consequence of this, though, will likely be that we need to default to emitting "fat" object files. For example today you can do:
and that "just works". If we were to omit bitcode entirely it wouldn't work as expected (would either not actually do LTO or would generate an error). So I think that the backwards compatible way to implement this change would be:
Given all that I think we can preserve everyone's use case today, while also switching all users to faster compilations by default. If you're not performing LTO, you never generate bitcode files. If you're performing LTO, you never generate machine code in intermediate rlibs.
I would personally weakly say "no" to be more strict, but I don't feel stringly either way. I feel like though there's not much reason to support this and it's easier to implement an error rather than codegen'ing more object files on the fly.
I do think it's pretty critical to keep LTO working for wasm. This is actually somewhat unfortunate though. In the meantime I think we'll either have to (a) work with LLVM to implement this because wasm does have custom sections, or (b) we'll need to keep logic for including
For LTO-ready rlibs on wasm though the