A good register allocation algorithm will always have problems with big subs, there is nothing that we can do about it.
I think that what "real compilers" do to solve this problem is implement two different algorithms: one for normal subs which tries to generate optimal code, and a naive one for very large subs with many virtual registers. That makes compilation much faster, and the execution penalty doesn't hurt too much. Actually, it's (for me) an open question whether the "good" register allocation should be the default one. Perl (and python and..) users expect blazing compilation times, so maybe we should reserve it for higher -O levels. But then, we won't know how bad are our compilation times until there are "real" programs written in perl6/parrot. -angel Leopold Toetsch wrote: > Dan Sugalski <[EMAIL PROTECTED]> wrote: > > Dunno what parrot thinks--it's not done yet. grep says 569 > > .locals and 473 temp PMC registers. > > I've now enabled some more code that speeds up temp allocation more > (~2.5 for 2000 temps in a unit). This needs that the usage range is > limited to 10 lines. If the code from a compiler looks like the > output from the program below, this works fine.
