|
From: Jeremy F. <je...@go...> - 2002-11-20 17:05:25
|
On Wed, 2002-11-20 at 02:08, Nicholas Nethercote wrote:
> I agree in principle. One question -- how would this affect the UCode?
> Would it look the same (eg. with all the %ESP PUTs and GETs) and then the
> code generator would combine multiple UInstrs into single x86 instrs? Or
> would the UCode look different.
I would definitely go with making it a special case of GET/PUT (ie, it
looks the same to the skins, and only register allocation/codegen cares
about the difference).
> As for saving/restoring %ESP on C code entry/exit, that would make each
> CCALL two instructions more expensive. For skins doing lots of CCALLs
> (eg. cachegrind) that might be a loss -- the CCALL extra expense could
> outweight the %ESP savings. Not sure. I suppose you could have a skin
> "lots_of_CCALLs" `need' that switches between the two approaches, but that
> would be a pain.
Cachegrind does a CCALL for every original instruction? In that case it
might get a bit slow. One way to fix this is to consider that ESP has
one of two homes: a set register and VGOFF_(m_esp)(%ebp). So long as we
guarantee that esp is in the right place at the end of a basic block, we
can do anything we like within it. So we can apply a lazy move strategy
to it, so if we save it in the baseBlock for a CCALL, we need only
retrieve it again if it gets modified or we're leaving the basic block.
> A related point: I've noticed that for skins inserting CCALLs, often a
> register is set and not touched for quite some time -- it's live range is
> big. If the register is a caller-save one (%e[acd]x) and one or more
> CCALLs occur between the set and use points, it would be better to spill
> it.
>
> For example:
> ...
> For each CCALL, %eax has to be saved/restored. If there are 2 or more
> CCALLs between %eax set and use, it would be better to set %eax and then
> immediately spill it, and then unspill it immediately before use.
Even better: If you've gone to the effort of spilling/saving on the
first ccall, then don't restore it until its actually needed. That is,
rather than pushing the live regs, just save them back into baseBlock,
and reload them when they're needed.
A harder problem is deciding when to do that in the absence of CCALLs,
since a long-life unused register is just causing pressure.
> I'm not sure. They have a "VPC" which I assume is a "virtual PC" in some
> of their diagrams. There's lots of detail in one of the papers about
> handling unusual control flow in Windows (callbacks, asynchronous
> procedure calls, exceptions, setjmp/longjmp) but I don't understand that
> stuff much at all. I'm not much use, sorry.
Last night I convinced myself that it is necessary to maintain the
virtual EIP while running, but now I can't think why. I think it can
always be computed on demand rather than needing to be maintained.
J
|