Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 5:53 PM +0100 11/13/04, Leopold Toetsch wrote: >>As the analysis of test errors of the new reigster allocator has >>shown, we have a problem WRT register allocation. This problem isn't >>new, but as the allocator is more efficiently reusing registers (or >>reusing them in a different way) it's exposed again.
> We don't really have that much of a problem. What we have is just > something more simple -- the target of a continuation marks the start > of a basic block. It is of course a new basic block. But setting the CFG correctly would need to create loops, that is an edge from all subcalls 1..n to previous subcalls 0..n-1. That could create big increases in CFG size. > ... That means that we have to assume everything we > don't get handed back from the function's dirty and should be > refetched. I'm fine with refetching lexicals, as - you say it - the may got rebound. But what about more static languages? > Or, alternately, if we declare that the top half of the register set > is preserved on function call and return These are preserved anyway - as well as the lower half. Please forget the upper/lower half notion coming from old savetop times. The failing gc_13 test is not failing because the register isn't preserved. It's failing because there is no indication that this register isn't reassignable due to the loop-effect of the continuation. [ refetching lexicals/globals ] > I'm perfectly fine in declaring that this is *only* legitimate in > mainline code, and that code generators don't have to deal with the > possibility that vtable or MMD function code has rebound names. Yes, as said I'm fine too with that. Perl/Python will do that anyway. But what about other languages? Are we forcing these to be as dynamic as the primary HLL targets? leo
