Re: [Valgrind-users] identifying conditionals during execution

[Chris E. <chr...@gm...>]

When I was working with VEX jump statements I noticed that I rarely if ever
saw the jk_call jump kind show up.  Instead the vast majority of everything
was boring.

Is there some default setting that causes this or perhaps was I maybe using
the wrong guest program to try and get jk_call jump kinds to show up?

 - Chris Eberz

On 5/9/07, Josef Weidendorfer <Jos...@gm...> wrote:
>
> On Wednesday 09 May 2007, John van Schie wrote:
> > Andreas S=E6bj=F8rnsen wrote:
> > > Is
> > > there any documentation on how I can differ these jumps from each
> > > other so that I can only look at the ones I am interested in?
> >
> > The way I use is by disabling constant propagation to make a difference
> > between direct and indirect jumps/calls
>
> Interesting. Callgrind does not distinguish jump kinds, and lackey only
> counts conditional jumps.
>
> However, Julian just added a simple branch prediction simulation into
> cachegrind
> (see SVN), and for distinguishing direct/indirect jumps, he does somethin=
g
> similar as you, but does not disable VEX optimizations.
>
> What are the scenarios where disabling this is necesssary?
>
> Did you also disable BB chasing? AFAIK, chasing can remove direct jumps i=
n
> the
> guest instruction stream when converting to IR. So any numbers about
> direct
> jumps go wrong.
>
> >   VG_(clo_vex_control).iropt_level =3D 0;
> >
> >   switch( bbOut->jumpkind ) {
> >
> >      case Ijk_Boring: {
> >        if( exprIsConst( bbOut->next ) ) {
> >          // it is a direct jump
> >        } else {
> >          // indirect
> >        }
> >      }
> >   }
> >
> > The same can be done for calls.
>
> Perhaps it is worth mentioning here that for PPC, the decision whether
> a branch instruction actually is a call or return, is only a heuristic
> in VEX.
>
> Josef
>
> >
> > But this slows the application downs quite a bit, because I have to
> > disable _all_ optimizations from coregrind to be able to disable
> > constant propagation.
> >
> > So if there is a better way (by using debug instructions), could
> > somebody elaborate on this? Because we use this tool for checking
> > optimizations of GHC (www.haskell.org/ghc) and any performance gain is
> > welcome.
> >
> > Cheers,
> >
> > John
> >
> >
> -------------------------------------------------------------------------
> > This SF.net email is sponsored by DB2 Express
> > Download DB2 Express C - the FREE version of DB2 express and take
> > control of your XML. No limits. Just data. Click to get it now.
> > http://sourceforge.net/powerbar/db2/
> > _______________________________________________
> > Valgrind-users mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-users
> >
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>