On 11-03-19 07:02 PM, Patrick Walton wrote:
I'm looking at the generated assembly code for std.rc (which is now
compiling, although it fails to link due to a strange mangling LLVM is
performing on duplicate native symbols). Even with all of LLVM's
optimizations, our hash insertion code has 4x the instruction count of
that of glib.
One major reason for this is that we have enormous overhead when calling
upcalls like get_type_desc() and size_of(). These calls are completely
opaque to LLVM. Even if we fixed the crate-relative encoding issues,
these calls would still be opaque to LLVM.
Most upcalls are trivial (get_type_desc() is an exception; I don't know
why it needs to exist, actually). For those, it would be great to inline
them. To do that, we need LTO, which basically means that we compile
rustrt with clang and link the resulting .bc together with the .bc that
rustc yields before doing LLVM's optimization passes. I think this would
be a huge win; we would remove all the upcall glue and make these
low-level calls, of which there are quite a lot, no longer opaque to LLVM.
Thoughts?
Eventually we want to implement our runtime library in rust, no? This
will move the places where we have to switch stacks, hopefully making
them less common.
With our runtime library in rust, there are two interesting problems
with the stack switching
*) How do to efficient kernel calls. It would be bad if we had to switch
stacks to go to libc and then the first thing the kernel does is switch
stacks again.
*) How to do LTO from one language to another. It would be interesting
for example to LTO LLVM into rustc. It would be really hard to inline a
generic C function into rust since that C function will not have GC
roots that would allow us to move the stack.
Patrick
Cheers,
Rafael
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
