From: "Will Coleda" <[EMAIL PROTECTED]> Date: Thu, 7 Aug 2008 11:30:34 -0400
On Thu, Aug 7, 2008 at 11:26 AM, Bob Rogers <[EMAIL PROTECTED]> wrote: > I once suggested a "null register allocator" that would do this > globally, but this is a better idea. The only use case I can think of > is debugging, particularly of the register allocator, but that's still > important. > > -- Bob Rogers > http://rgrjr.dyndns.org/ I not convinced that debugging the register allocation from -inside PIR- makes sense. -- Will "Coke" Coleda Then think of it as a tool that gives the HLL compiler more control over register allocation. The advantage may not be huge, but it is not zero, and the cost is pretty low. ================ From: chromatic <[EMAIL PROTECTED]> Date: Thu, 7 Aug 2008 09:58:37 -0700 . . . In theory, that's what the vanilla register allocator does. In practice, somehow something sometimes turns on the graph-based allocator, which has a couple of bugs. PGE trips this occasionally. -- c What I suggested was a new allocator that mapped (e.g.) $Pn to Pn, without the compaction done by the vanilla register allocator. Currently, there are two mappings between the HLL var to the Parrot register: var ==> $P register ==> P register. Neither is recorded anywhere, but has to be gleaned from debugging output produced by the compilers. So being able to dispense with one of them on demand would be useful for debugging, IMHO. Of course, someday these mappings need to be recorded so HLL debuggers can use them. But that's another story. -- Bob
