Fwd: Re: Statically linking rustrt

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Fwd: Re: Statically linking rustrt

Patrick Walton
Forgot to send this to the list. Sending here, with an addendum I missed:

On 3/19/11 4:45 PM, Graydon Hoare wrote:
> "Our hash-insert code is 4x the size of glib's hash-insert code"
> or
> "Our hash-insert code is 4x the size of all of glib combined"
> ?
>
> I'd believe either right now, and if we're only talking about the
> former, I'd be really surprised / pleased!

4x the size of glib's hash-insert code.

 > size_of? Hm. That's not an upcall. I thought we were generating the
 > size calculation code inline (on demand, from GEP_tup_like).

We are, but it's called by map.rs.

> It needs to exist to acquire derived type descriptors, dynamically. They
> are not static. Though we can probably do a little analysis and figure
> out which cases are degenerate -- are static -- and dodge the upcall.
> And/or consolidate multiple redundant upcalls occurring in the same
> frame / execution context. We're doing everything as simple as possible
> now.

Something I thought of is that we could locally allocate derived tydescs
and pass them by alias in most cases. I *think* the only cases in which
derived tydescs escape is via bind or objects (correct me if I'm wrong).
In those cases trans still generates the slower upcall. But in the other
cases, trans could just generate the tydescs inline in the current stack
frame. LLVM might even be able to elide the generation of redundant
parts automatically when there's only a little bit of the tydesc needed
and/or collapse duplicate tydescs, both via SROA.

On a completely unrelated note, interestingly enough, rustc doesn't
compile std.rc that much slower than rustboot does.

Patrick