3 ms·
upvar and uplevel are a significant barrier to optimisation, but not to plain compilation — the hardest part would be autovivification of fresh up-locals, and e
by 082349872349872 2y ago
upvar and uplevel are a significant barrier to optimisation, but not to plain compilation — the hardest part would be autovivification of fresh up-locals, and even that sounds like an extra indirection could reasonably handle it?
EDIT: looks like tcl doesn't bytecode uplevel expressions, so I must be missing a catch?
- kragen 2y agoyeah, what i was thinking of specifically was that they would be a major barrier to optimization, which is the benefit one hopes for from compilation to be specific, it would be pretty hard to optimize a non-leaf procedure if any other procedure it called were able to violate any assumptions you'd made when optimizing it. elided redundant type checks, perhaps to specialize a proc? the proc it called changed the type of one of its variables. constant propagation? that proc changed the value of the variable you thought was constant. strength-reduction? likewise. you aren't going to get much dead code elimination without constant propagation. invariant hoisting? how are you going to figure out what's invariant if a proc you're calling inside the loop could change any of the variables used in it? register allocation? better have a way for upvar and uplevel to look up which register it was