freenode/#sicl - IRC Chatlog
Search
13:16:40
Bike
so about avoiding redundant ast/hir in inlining. say we have (lambda (x) (values (car x) (lambda () (car x)))). we'd essentially want that to turn into (lambda (x) (flet ((car ...)) (values (car x) (lambda () (car x))))). if we decide not to inline, the lambda's closure vector is then larger than it has to be, and in some cases it could force something to be a closure that wasn't.
13:17:25
Bike
i think if we decide to really notinline and not partially evaluate or anything we should have a way to go back to a global call, so that we don't just make things worse.
13:27:42
beach
I mean, CAR was proclaimed INLINE, so if it is not, in fact, inlined, there must be a reason for that. What situations would make that so, and how frequent are they?
13:36:51
Bike
its not a problem at the moment since if a function is incorporated (as you put it yesterday) it is inlined
13:37:35
beach
So I suggest we start thinking about policies first, then, when those policies are implemented, we check how big a problem it is.
13:38:07
beach
By "first", I don't mean "right now". I mean "before trying to guess whether what you brought up is a problem".
13:49:12
Bike
if we have (lambda (x) (values (car x) (car x))) we have two copies of the AST for car
13:50:42
beach
If so, we should probably eliminate the copying because the ASTs are not modified as far as I can tell.
13:51:03
Bike
hoisting mutates the ast so we have to copy it. but i'm a little confused with the terminology sorry. i mean they each uh... maybe it isn't otherwise a problem actually
13:52:03
Bike
if we didn't copy for hoisting i guess we'd end up with two lexical-asts but they'd have the same function-ast value so it would be fine, maybe.
13:52:08
beach
You can even generate HIR code for CAR and store it together with the function entry.
14:05:39
Bike
yeah i think i was confusing myself. nevermind. i thought it was going to be more of an ordeal.