|
From: Nicholas N. <nj...@ca...> - 2002-11-20 10:09:02
|
On Tue, 19 Nov 2002, Julian Seward wrote: > > Perhaps a slightly simpler approach would be to dedicate a register to > > ESP rather than a memory location, so that it is persistently in > > register across basic blocks. > > [...] > > Will still need to work out appropriate times to save ESP into the > > baseblock for when control enters C code. > Yes, this seems a good compromise. We already played with the issue of > 5 vs 6 allocatable registers and it makes very little difference at least > to memcheck, so perhaps it would be ok to give one to %ESP. 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. If the latter, how would this interact with MemCheck's instrumentation? It feels to me like this would be a good thing to keep within the code generator if possible, so that %ESP is not treated any differently from a UCode point-of-view, which makes life easier for skins. 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. > > 2. Using trace caching will lengthen the effective size of a basic > > block, and thereby amortize the register load/save over more > > instructions 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: set %eax ... code not using %eax, with multiple CCALLs ... use %eax 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. I'm not even sure if this happens a lot, but if it is maybe something could be done in register allocation to avoid it. ---- > Nick, one thing you seemed to not comment on is ... > > > addl $2, 36(%ebp) (the INCEIP) > > ie, we keep exact track of %eip; does DynamoRIO ? What sort of > exception model at they presenting? 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. N |