Bill Coffman <[EMAIL PROTECTED]> wrote: > Interesting. I did a little more research, and checked out a fresh > CVS tree.
I've committed the tailcall patch a minute ago with that one line changed in reg_allog.c - please rediff. > ... I did nothing more than insert a conflict checker into > reg_alloc.c > The routine you mentioned, allocate_wanted_regs() doesn't assign > wanted regs if in conflict, but as far as I can tell, there's no check > on the integrity of precolored nodes. Not quite sure what the correct > behaviour is for allocator, when it's given conflicts. These precolored wanted_regs are created for function arguments and return values only (and for registers used during function calls). And indeed, if there is a conflict the register shouldn't get a color. Seems to work now, as I don't get these test failures anymore. > I saw 'K' compounded key somewhere, but don't know what it is. It's a notion for a key like in: set P1, P2["abc" ; 1] set_p_p_kc The last arg is a r->set := 'K' and points to a chain of other SymRegs. It's actually a PMC entry in the contant table, where the color is the index in constants. >... I know > reg_alloc.c pretty well though. Offhand I'd say it's not handled in > reg_alloc. Maybe it should be? No, that's ok. Constants are handled in imcc/pbc.c and aren't affected by reg_alloc.c at all. > ~Bill leo
