profiling go

[Matthew Fluet]

> > That would be nice, but the codegen is only keeping values in registers
> > across basic blocks if the value was put in a (pseudo-)register by the
> > backend register-allocator.  So, all three of these values are being used
> > from their stack locations and are written back to the stack before the
> > end of the basic block.
>
> Yuck.  We really need a rethink of having two different register allocators.
> The backend one is so stupid because it will always keep a CPS var in a stack
> slot if it is ever live across a nontail call.  Maybe we've already discussed
> this, but is there any simple fix in the codegen that might undo some of this
> stupidity?

The best solution, IMHO, would really be to change the CPS->Machine
register allocator so that at each limitCheck, farJump, and prim that
enters the runtime, it generates a mapping from pseudo-regs to stack
slots.  That way, everything is in pseudo-regs and the codegen would take
care of moving values to the stack at the right times.  (This would be
nice for limitChecks, I think, because we could set it up so that the
moves occured after the frontier check; if you didn't need to GC, you
wouldn't pay for setting up the stack.)

As for a codegen fix/hack, I could see what happens when I treat stack
slots like pseudo-regs; the real issue is that I don't have liveness info
on stack slots; the implicit assumption is that a write to memory on the
stack has to occur before we change blocks.