On Mon, 8 Nov 2004 12:20:19 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote: > Jeff Clites <[EMAIL PROTECTED]> wrote: > > On Nov 8, 2004, at 1:34 AM, Leopold Toetsch wrote: > > >> If frames aren't adjacent, normal argument copying can be done anyway. > > > This would seem to require the same types of runtime checks that you > > are objecting to below, > > Not runtime. The register allocator knows the amount of needed > non-volatiles and volatile registers. Depending on that a call can place > arguments directly into the incoming regs of the caller or not. Then if > at runtime copying is needed (because e.g. frames aren't adjacent), the > function arguments are copyied. This is fully transparent. > > > I discussed that in item (1) under "Further notes". > > Yep, saw that then ;) > > >> It's not needed. I've a better scheme in mind, which addressess > >> efficieny as well as argument passing. > > > And spilling? > > Well, I'm proposing a variable-sized register frame. With very little > additions we could run with more then 32 registers per kind (there are a > few bitmasks currently that would need adaptions, but not much).
I think this is a great idea. Mostly, I was thinking of the case where there are less than 32 registers needed. The allocator can try to reduce the number of registers that will need to be used. I think that addressing could become an issue is there are too many registers, but I still haven't figured out how the bytecode looks yet. > But basically, spilling should not be needed at all, if the register > allocator isn't as broken as it now is. Dan got some really evil > subroutines, so we have RL test cases. We'll see. In that case, I'll focus on the register renaming, live-range analysis, etc. The memory leak, which might not be actually lost memory, but just wasteful useage of memory, is pretty much related to the spill code. Most of the grotesqueness of the allocator is in the spiller. If this has a high probability of changing, I'll focus on other stuff, like register renaming, which is a lot harder, but with higher longterm payoff. In light of this, I think I'll send in my patch, in case it is helpful. The problem is that some routine outside of imc_reg_alloc() is sending in conflicting register preallocation. My code does lot's of assertions, and finds this, one way or another. I'll put in a variable to turn off color consistency checking, which will probably then pass the tests. Bill > > > JEff > > leo >
