Short IRC transcript on the topic

06:53 < pkhuong> I believe you had some stuff on quicker compilation? Is there any preliminary branch, patch set or notes I should point people to? 07:01 <@nikodemus> pkhuong: not as such 07:02 <@nikodemus> i can write a quick braindump 07:02 <@nikodemus> IIRC. the biggest timesink is constraint propagation. 07:03 <@nikodemus> IIRC. the trickiest thing about eliminating it is that we have a bunch of places that assume that certain things are always optimized. 07:03 <@nikodemus> so if you eliminate it, you get "correct" code that the rest of the system cannot deal with 07:05 <@nikodemus> being a silly young thing, i was working on essentially adding IR0 which would have been a fast way to get those minimal things sorted out. I still think that's possible, but it probably isn't the best way to go about it... 07:07 <@nikodemus> i think it would be a reasonable approach to just diable it, and see where things break, and start fixing the places that make those assumptions 07:07 <@nikodemus> EOBD 07:07 <@nikodemus> s/diable/disable/ 07:09 < pkhuong> sounds right to me as well. 07:12 < pkhuong> So, I see where constraint propagation can be simplified... we need quick but conservative type union/intersection... csubtypep as well, I guess. 07:13 < pkhuong> Then, see what happens to the transforms, and play whack-a-mole. 07:13 <@nikodemus> IIRC a typical breaked is from eg (coerce x 'list) => (the list (if (listp x) x (convert-to-list x))) sort of transforms 07:14 < pkhuong> how does that break? 07:15 <@nikodemus> don't remember the details. maybe when X is known not to be a list due to a declaration? 07:16 <@nikodemus> so you end up with something like (the list (the (not list) x)) 07:16 <@nikodemus> which the compiler won't like 07:16 <@nikodemus> or maybe it was IR1-OPTIMIZE that was needed to kill the IF 07:17 < pkhuong> oh yeah. 07:17 < pkhuong> constraints need ir1 optimise to kill (if [x] [block] [same block]) into (progn [x] [block]) 07:19 <@nikodemus> and (if [always false] [will cause a runtime error] [ok])? 07:19 <@nikodemus> because some of the breakaged were WARNINGs due to compiler thinking it sees something that will break at runtime for sure 07:19 <@nikodemus> breakages, even 07:19 < pkhuong> I think that's all right, wrt codegen. I changed that to style warnings because of ppcre 07:20 <@nikodemus> oh 07:20 < pkhuong> If there's a branch on the path (well, it's a hack, but catches most cases), the warning is downgraded to a style warning. 07:21 <@nikodemus> right 07:21 <@nikodemus> then there are our always-translatable things, i guess 07:22 < pkhuong> shouldn't we get nearly all of those right just with the defknowned types? 07:22 <@nikodemus> and many many transforms which should not be done unless we're actually going to compile things as well as we can 07:22 <@nikodemus> most, i think 07:22 < pkhuong> there's that. workingness would be a good first step though (: 07:23 <@nikodemus> and the rest should probably not be always-translatable, but something like mostly-translatable :) 07:23 < pkhuong> right. 07:24 <@nikodemus> yeah, and eliminating transforms is the completely wrong first step, because /almost/ any problematic code a transform can inject can also come from a user 07:25 <@nikodemus> though i'm willing to give a pass to eliminating transforms that produce (sb-foo:%something-magic ...) if they turn out to be a problem 07:25 < pkhuong> yes and no... We could only run CP once. User code would benefit from minimal constraints, but deftransformed code not. 07:26 <@nikodemus> sure, but in deep CMUCL time CP used to be completely optional 07:26 <@nikodemus> i'd sort of like to restore that 07:26 < pkhuong> right. 07:26 <@nikodemus> oops. make that "would like to see that restored" :) 07:27 < pkhuong> Also, our transforms go out of their way to depend on CP: expand into a lambda without type declaration on the arguments? 07:28 <@nikodemus> the deftransform could magically add most of the type information there, i think 07:28 <@nikodemus> (a case for truly-type declaration?)