On 11/15/2013 03:01 AM, Niko Matsakis wrote:
A few quick questions and comments:
On Fri, Nov 15, 2013 at 12:09:28AM -0800, Alex Crichton wrote:
As a side node, after writing all this up, I remembered LTO as an
option for generating libraries. I don't think I know enough about LTO
to be able to say whether it would fit in this system or not, but my
basic understanding is that an LTO library is just "IR in a box". We
could add a --lto output option which has pretty much the same
semantics as the --rlib option, but with a different format. Again
though, I haven't thought how native libraries would fit into that
scenario, but I believe that we could fairly easily accommodate LTO in
a system like this.
Unless I'm missing something, it seems like what we would want to do
is to have the .rlib file contain LLVM IR, at least for the Rust code
that was compiled / statically linked against. If we can, I think we
should just make LTO happen by default whenver you statically link,
rather than having it be a separate option, but it is fine if that
doesn't work yet in the first version (e.g., because .rlib is just a
.o file). Still I agree that your scheme accommodates it just fine.
I'm not sure I agree that LTO should be the default - for large
applications it's going to be brutal on LLVM and I imagine we'll quickly
hit scenarios where we run out of RAM. For something like a production
Servo I imagine we would go to whatever lengths necessary to LTO
everything, but it would be cheaper and faster to do normal static
linking. Some empirical evidence about how far we can push LLVM's LTO
would be helpful though.
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
