|
From: Josef W. <Jos...@gm...> - 2005-07-29 19:12:39
|
On Friday 29 July 2005 19:54, you wrote: > On Fri, 29 Jul 2005, Josef Weidendorfer wrote: > > Looking to get the REP case right, I noticed that you insert calls to the > > simulation always after a guest instruction. In VG 2.x, this was the > > other way round. > > > > The effect of the current instrumentation is that log_1I_0D_cache_access > > is called for conditional jumps only in the fall-through case. > > > > Was this change done intentional? > > [sigh] The REP handling has changed so many times that I can't remember > how or why it is what it is. I can certainly believe that the 3.0.0 > Cachegrind is not doing the right thing. But that is not about REP. This problem is at the end of every BB ending in a conditional jump, so it is not something to ignore IMHO. I just found out that VEX sometimes inverts the condition in conditional jumps, so the simulator is more or less not called for conditional jump instructions randomly. > > I reverted this behaviour. See my change in CLG_(instrument) in the > > attached file (i renamed handleOneStatement to collectStatementInfo). > > > > In handleOneStatement, you did not forward ABI hints. > > I thought that ABI hints are used to generate better code in the VEX > > backend? > > What are ABI hints? I think these are pseudo-statements VEX is producing to give hints from the frontend to the backend. Julian, is this correct? Josef > > Nick |
|
From: Nicholas N. <nj...@cs...> - 2005-07-29 19:30:42
|
On Fri, 29 Jul 2005, Josef Weidendorfer wrote: > But that is not about REP. This problem is at the end of every BB ending in a > conditional jump, so it is not something to ignore IMHO. > I just found out that VEX sometimes inverts the condition in conditional > jumps, so the simulator is more or less not called for conditional jump > instructions randomly. Oh, sorry, I misread your message. That is bad, I should fix it before 3.0.0 ships. Thanks for spotting it. N |
|
From: Julian S. <js...@ac...> - 2005-07-29 19:32:13
|
> But that is not about REP. This problem is at the end of every BB ending in
> a conditional jump, so it is not something to ignore IMHO.
> I just found out that VEX sometimes inverts the condition in conditional
> jumps, so the simulator is more or less not called for conditional jump
> instructions randomly.
I have to say .. I think it may prove difficult to get
{cache,call}grind to treat rep instructions as a single insn,
regardless of how many iterations it does. Particularly if vex is
going to unroll the BB containing the IR for the instruction. That
said, I'll help if I can.
Can you send an example of this conditional inversion? I'm not really
sure what you mean.
> > > I reverted this behaviour. See my change in CLG_(instrument) in the
> > > attached file (i renamed handleOneStatement to collectStatementInfo).
> > >
> > > In handleOneStatement, you did not forward ABI hints.
> > > I thought that ABI hints are used to generate better code in the VEX
> > > backend?
> >
> > What are ABI hints?
>
> I think these are pseudo-statements VEX is producing to give hints from the
> frontend to the backend. Julian, is this correct?
Sort-of. They are hints from the front end to the tool. So far the
only use is on amd64, to emit a hint that a call or return instruction
is just about to be executed. In that case memcheck needs to mess with
the memory permissions for -127(%rsp) .. 0(%rsp) and so it generates
an appropriate helper call when it sees the hint. I think it's a hack
but I couldn't think of anything cleaner.
J
|