Re: [Valgrind-developers] Speeding up cache simulation

[Julian S. <js...@ac...>]

> > All looks fine to me.  This is an implementation-only change, yes?
> 
> Yes.
> At least, it is expected to be.
> 
> That's actually a tricky problem. When the cachegrind binary changes,
> also a lot of client addresses will change, and there can be new/other
> cache conflicts misses.

I am a bit surprised by that, since the cachegrind binary is loaded
at 0x38000000, which is far away from the load address for the client
(0x400000) and its libraries.  Are you sure you are not seeing the
effect of ASLR in the client?  Just a guess.


> Sounds good.
> Actually, I did not do "Ir -> IrNoX" (or similar) to reduce patch size.

Storage is cheap these days :-)  I prefer readability over minimising
patch size :)

> As far as I understand, for any Ir which is not the first in a SB or
> after a side exit, the number of executions must be the same as for the
> previous Ir. So a post-processing should be able to correct the
> counts.

Yes, I think that is correct.  I think an equivalent way to say it
is: if you partition the IR sequence for a SB at the side-exit points,
then each sub-sequence you get from this is a single-entry, single-exit
block, and so every IR statement within the block (hence, every guest
insn in it) is executed the same number of times.  Does that sync with
your understanding?

J