On Fri, May 31, 2013 at 2:45 PM, Graydon Hoare <[email protected]> wrote:
> On 13-05-31 11:55 AM, Daniel Farina wrote:
>> I've been poking around in rustc, after noting that compile times are
>> much longer than I'd expect.
>>
>> So while some micro optimizations may help, I'm wondering if anyone
>> has given a lot of thought as to how to make the llvm passes faster or
>> parallel, because this is something like more than half the battle.
>>
>> What's worrisome is Rust's typical compilation model encourages large
>> crates that are one compilation unit, unlike, say, a pile of
>> individual C files each emitting an object file that admittedly must
>> be linked... but at least the instruction selector can be run in
>> parallel. Does this present a sticky problem?
>
> Long term, we don't think so. Short term, it's annoying to all of us;
> we're struggling with splitting time between completing features, fixing
> bugs, working on residual bits of lingering design problems, and (sadly,
> often last) optimizing the codegen. We should spend more time on it.
>
> Most of the problem comes from us generating too much LLVM code (and
> code that is hard for LLVM to work with). Much of _that_ comes from
> technical debt in the lowering pass, src/librustc/middle/trans. By
> necessity, trans is one of the oldest pieces of the compiler; and by
> unfortunate historical reality, we've changed enough assumptions about
> runtime representations enough times through the life of this compiler
> that trans is now generating a lot of unnecessary code.
I see. I did notice the translation pass is one of the other big
fish, the other one being type checking. Looks like the translation,
in addition to taking a long time, also generates a lot of work for
LLVM with that time. Is the general idea there that employing a
better understanding of Rust's higher level structures will allow
quicker elimination of a lot of the low-level IR? Is there a general
flavor to the unnecessary code being generated that is known, or is
this a subject of some research?
> There is some instrumentation there to measure code generation by
> source. A few useful incantations are:
>
> # count LLVM instructions by trans function-call stack
> $ rustc -Z count-llvm-insns foo.rs | xdu
>
> and:
>
> # list symbols in the resulting binary sorted by size
> $ objdump -t libfoo.so |
> awk '/\.text/ { printf("%d\t%s\n", strtonum("0x" $5), $6) }' |
> c++filt |
> sort -n
>
> and:
>
> # visualize the instruction graph of a given compilation unit
>
> # first generate foo.bc, the llvm bitcode for foo.rs
> $ rustc --save-temps foo.rs
>
> # then generate a dot file for every function's CFG
> $ opt -analyze -dot-cfg foo.bc
>
> # then do graph layout on, say, the "::main" dot file
> # and convert to SVG; pick other dot files for other functions
> $ dot -Tsvg -ograph.svg <(c++filt <cfg._ZN4main17_*.dot)
>
> # then take a look at it
> $ firefox graph.svg
Thanks, this is quite helpful.
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
