freenode/#clasp - IRC Chatlog
Search
12:16:35
drmeister
Macintosh HD 1 is the hard drive of my old computer accessed through the cable. The numbers are slow and all over the place.
12:55:56
Bike
okay so here's what i'm thinking about inlining. first off, if we have the function body and the call site, there's no way we "can't" inline. We just need to make sure we allocate the ex-callee's environment at the ex-call site - conceptually, inline it.
12:56:19
Bike
this might not work for partial inlining, but i'm not really concerned with partial inlining
12:57:32
Bike
second, we've been talking about unifying handling of simple variables with closure variables, but i think it would make more sense to unify closure variables with data structures. The only difference between a cell and a cons is that one can be enclosed over and the other can be used as an argument. I don't think any analysis that could cover one couldn't cover the other.
12:58:29
Bike
simple (like, non closed over) variables are like data structures that are only read from and written to- not even used for identity - which is why we can put them in registers etc. I think that's enough of a difference that we should treat them differently, and we could reduce data to variables in some cases.
12:59:56
Bike
so i'm thinking we should do cell conversion fairly early and possibly have different optimization passes to allow handling data.
13:01:19
Bike
for inlining, i think we should convert lets to assignments rather than make them functions, just for efficiency reasons. we'd mark the assignments as "creating" variables, which we probably want to allow anyway for like, catch-instruction. then segregate lexicals can replace them with create-cell instructions if necessary without doing the dominance analysis stuff.
13:19:38
Bike
Also it would rule out inlining functions calls that aren't really obvious, which is occasionally useful.