profiling go

[Matthew Fluet]

> > I'm  confused  by  the  constant  re-loading of %ecx (x_491 in the CPS code).
>
> I'm betting it's because x_491 is a pointer and is live across a limit check,
> and hence we won't let it live in a register.
>
> I would think we could at least keep x_494 and x_495 in a register around the
> loop.

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.

> > Also the storing of %eac in localuint.
>
> I agree.  I don't know why we didn't use another register.

Essentially, it's the one-pass register allocation; I don't know that eax
is going to be trashed when I do register allocation for the movzbl
instruction.  There are hooks for propagating some hint information
backwards, and I'm thinking about how best to catch this case.

> I don't understand the "xorl %edx, %edx".

Henry was correct in that it was related to my handling of the mul
instruction.  I was treating mul, div, and mod instructions pretty much
the same; the div and mod require the divisor to be zero- or sign-extended
into edx:eax, and mul was as well.  Easy enough to fix it so that
multiplications do not get the zero or sign extension.