|
From:
<and...@gm...> - 2007-04-19 18:18:27
|
Is Valgrind capable of identifying conditionals during execution?
For instance if we have the binary corresponding to the following source code:
int main(){
int x = 0;
if ( false )
x = 2;
}
can Valgrind correctly identify the 'if ( false )' statement as a
conditional during execution?
Thanks
Andreas
|
|
From: Olly B. <ol...@su...> - 2007-04-19 21:22:12
|
On 2007-04-19, Andreas Sæbjørnsen <and...@gm...> wrote:
> Is Valgrind capable of identifying conditionals during execution?
>
> For instance if we have the binary corresponding to the following source code:
>
> int main(){
> int x = 0;
> if ( false )
> x = 2;
> }
>
> can Valgrind correctly identify the 'if ( false )' statement as a
> conditional during execution?
There probably won't be any trace of that in the compiled code.
Certainly not if the compiler is optimising, and it's common to do dead
code elimination even when not optimising (because doing so actually
typically speeds up compilation overall and doesn't make using a
debugger more difficult).
If I compile your example with GCC 4.1.2 without optimisation, the
assembler doesn't have a test of false or an assignment of 2 to
anything.
Cheers,
Olly
|
|
From:
<and...@gm...> - 2007-04-19 21:38:05
|
This is just an example of what I meant when I said conditional
although I am aware that in this specific instance it is not doing
anything useful so it can be optimized away. In a real code I am only
interested in the conditionals which is not optimized away. Do you
know if Valgrind at execution time is capable of identifying the
conditionals which has not been optimized away?
Normally I would use a disassembler for this, but it would be great if
you could identify the if statements using Valgrind so that I could
instrument the conditionals in the same way as functions are
instrumented.
Thanks
Andreas
On 4/19/07, Olly Betts <ol...@su...> wrote:
> On 2007-04-19, Andreas S=E6bj=F8rnsen <and...@gm...> wr=
ote:
> > Is Valgrind capable of identifying conditionals during execution?
> >
> > For instance if we have the binary corresponding to the following sourc=
e code:
> >
> > int main(){
> > int x =3D 0;
> > if ( false )
> > x =3D 2;
> > }
> >
> > can Valgrind correctly identify the 'if ( false )' statement as a
> > conditional during execution?
>
> There probably won't be any trace of that in the compiled code.
>
> Certainly not if the compiler is optimising, and it's common to do dead
> code elimination even when not optimising (because doing so actually
> typically speeds up compilation overall and doesn't make using a
> debugger more difficult).
>
> If I compile your example with GCC 4.1.2 without optimisation, the
> assembler doesn't have a test of false or an assignment of 2 to
> anything.
>
> Cheers,
> Olly
>
>
> -------------------------------------------------------------------------
> 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
>
|
|
From: Nicholas N. <nj...@cs...> - 2007-04-20 02:17:44
|
On Thu, 19 Apr 2007, Andreas S=E6bj=F8rnsen wrote: > This is just an example of what I meant when I said conditional > although I am aware that in this specific instance it is not doing > anything useful so it can be optimized away. In a real code I am only > interested in the conditionals which is not optimized away. Do you > know if Valgrind at execution time is capable of identifying the > conditionals which has not been optimized away? It can. You'll probably have to write a new tool, though. The "Lackey"=20 tool (in lackey/lk_main.c) does some counting of branches with its=20 --basic-counts option. Nick |
|
From: John v. S. <jc...@cs...> - 2007-04-20 06:03:40
|
Nicholas Nethercote wrote: > > It can. You'll probably have to write a new tool, though. The "Lackey" > tool (in lackey/lk_main.c) does some counting of branches with its > --basic-counts option. > > Nick To add to this, as a matter of fact, I've recently created a tool that counts the direct/indrect branches, direct/indirect calls, conditional jumps and returns. Maybe this is a good starting point for you to begin with Andreas. Please let me know if you are interested. Cheers, John van Schie |
|
From:
<and...@gm...> - 2007-04-20 16:09:33
|
> > It can. You'll probably have to write a new tool, though. The "Lackey" > > tool (in lackey/lk_main.c) does some counting of branches with its > > --basic-counts option. Thanks. I really appreciate this info. > To add to this, as a matter of fact, I've recently created a tool that > counts the direct/indrect branches, direct/indirect calls, conditional > jumps and returns. Maybe this is a good starting point for you to begin > with Andreas. Please let me know if you are interested. Nicholas, if you want to share this tool I am very thankful. It sounds like it would be a good starting point for my work. Andreas |
|
From: Josef W. <Jos...@gm...> - 2007-04-20 16:39:59
|
[resent without any screenshot for the mailing list] On Friday 20 April 2007, John van Schie wrote: > Nicholas Nethercote wrote: > > > > It can. You'll probably have to write a new tool, though. The "Lackey" > > tool (in lackey/lk_main.c) does some counting of branches with its > > --basic-counts option. > > > > Nick > > To add to this, as a matter of fact, I've recently created a tool that > counts the direct/indrect branches, direct/indirect calls, conditional > jumps and returns. Maybe this is a good starting point for you to begin > with Andreas. Please let me know if you are interested. Callgrind also collects (conditional) jumps when you pass the "--collect-jumps=yes" (in addition to "--dump-instr=yes") option. KCachegrind can show this jump info in the assembler view. However, jump annotation in the source view currently is confusing, as jumps between source lines because of instruction reordering are not shown. Another note: With PPC, there are not really call and return isntructions. Callgrind has some (currently quite bad) heuristic to see what jump can be interpreted as a call/ret; in this szenario, you also get conditional calls and conditional returns, which do not exist with x86 and are not handled correctly by callgrind :-( I get the feeling that there are a lot of useful tools "out in the wild", and everybody would profit if we chould collect these even in an experimental stage, as already was discussed some time ago. Josef |
|
From:
<and...@gm...> - 2007-04-24 02:26:49
|
Thank you very much for all your suggestions. John send me his code and I am going to play around with it tomorrow. Andreas On 4/20/07, Josef Weidendorfer <Jos...@gm...> wrote: > On Friday 20 April 2007, John van Schie wrote: > > Nicholas Nethercote wrote: > > > > > > It can. You'll probably have to write a new tool, though. The "Lackey" > > > tool (in lackey/lk_main.c) does some counting of branches with its > > > --basic-counts option. > > > > > > Nick > > > > To add to this, as a matter of fact, I've recently created a tool that > > counts the direct/indrect branches, direct/indirect calls, conditional > > jumps and returns. Maybe this is a good starting point for you to begin > > with Andreas. Please let me know if you are interested. > > Callgrind also collects (conditional) jumps when you pass the > "--collect-jumps=yes" (in addition to "--dump-instr=yes") option. > KCachegrind can show this jump info in the assembler view > (see e.g. screenshot attached). > However, jump annotation in the source view currently is confusing, > as jumps between source lines because of instruction reordering > are not shown. > > Another note: With PPC, there are not really call and return isntructions. > Callgrind has some (currently quite bad) heuristic to see what jump > can be interpreted as a call/ret; in this szenario, you also get conditional > calls and conditional returns, which do not exist with x86 and are not handled > correctly by callgrind :-( > > I get the feeling that there are a lot of useful tools "out in the wild", > and everybody would profit if we chould collect these even in an > experimental stage, as already was discussed some time ago. > > Josef > > |
|
From:
<and...@gm...> - 2007-05-08 19:44:43
|
With John's help I have been able to identify all the jumps in an
application and counting them. But I get way more jumps than I really
expected (see below) and I am curious where they come from. Is there
any documentation on where all (>200,000) the jumps come from? 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 application I am instrumenting is:
int main(){
int x =2;
if(x==2){
}
};
And the output I get is:
==17918== Jumps direct
==17918== counted: 145,795 ( 38%)
==17918== Jumps indirect
==17918== counted: 2,994 ( 0%)
==17918== Calls direct
==17918== counted: 13,341 ( 3%)
==17918== Calls indirect
==17918== counted: 228 ( 0%)
==17918== Returns
==17918== counted: 13,629 ( 3%)
==17918== Conditionals
==17918== counted: 202,644 ( 53%)
==17918== Other
==17918== counted: 52 ( 0%)
Andreas
On 4/20/07, Josef Weidendorfer <Jos...@gm...> wrote:
> On Friday 20 April 2007, John van Schie wrote:
> > Nicholas Nethercote wrote:
> > >
> > > It can. You'll probably have to write a new tool, though. The "Lackey"
> > > tool (in lackey/lk_main.c) does some counting of branches with its
> > > --basic-counts option.
> > >
> > > Nick
> >
> > To add to this, as a matter of fact, I've recently created a tool that
> > counts the direct/indrect branches, direct/indirect calls, conditional
> > jumps and returns. Maybe this is a good starting point for you to begin
> > with Andreas. Please let me know if you are interested.
>
> Callgrind also collects (conditional) jumps when you pass the
> "--collect-jumps=yes" (in addition to "--dump-instr=yes") option.
> KCachegrind can show this jump info in the assembler view
> (see e.g. screenshot attached).
> However, jump annotation in the source view currently is confusing,
> as jumps between source lines because of instruction reordering
> are not shown.
>
> Another note: With PPC, there are not really call and return isntructions.
> Callgrind has some (currently quite bad) heuristic to see what jump
> can be interpreted as a call/ret; in this szenario, you also get conditional
> calls and conditional returns, which do not exist with x86 and are not handled
> correctly by callgrind :-(
>
> I get the feeling that there are a lot of useful tools "out in the wild",
> and everybody would profit if we chould collect these even in an
> experimental stage, as already was discussed some time ago.
>
> Josef
>
>
|
|
From: Josef W. <Jos...@gm...> - 2007-05-09 03:05:16
|
On Tuesday 08 May 2007, Andreas S=E6bj=F8rnsen wrote:
> With John's help I have been able to identify all the jumps in an
> application and counting them. But I get way more jumps than I really
> expected (see below) and I am curious where they come from.
What did you expect?
As VG analyses the client code from the very first instruction,
this includes initialization of all shared libraries linked.
The numbers should be significantly lower with static linkage.
=46or /bin/true, which is something like "int main() { return 1;}",
I get similar JCC counts in the output of "lackey" on my OpenSuse 10.2
system, so your results should be Ok.
> Is there=20
> any documentation on where all (>200,000) the jumps come from?
This probably is all from the runtime linker and glibc.
As I see, /bin/true involves more than 40,000 jumps alone in strcmp()...
> Is=20
> 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?
You can distinguish guest instructions according to debug info
attributed to them.
Josef
|
|
From: John v. S. <jc...@cs...> - 2007-05-09 07:37:36
|
Andreas Sæbjørnsen 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
VG_(clo_vex_control).iropt_level = 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.
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
|
|
From: Josef W. <Jos...@gm...> - 2007-05-09 08:54:01
|
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?
>=20
> 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 cache=
grind
(see SVN), and for distinguishing direct/indirect jumps, he does something
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 in =
the
guest instruction stream when converting to IR. So any numbers about direct
jumps go wrong.
=20
> VG_(clo_vex_control).iropt_level =3D 0;
>=20
> switch( bbOut->jumpkind ) {
>=20
> case Ijk_Boring: {
> if( exprIsConst( bbOut->next ) ) {
> // it is a direct jump
> } else {
> // indirect
> }
> }
> }
>=20
> 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
>=20
> 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.
>=20
> 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.
>=20
> Cheers,
>=20
> John
>=20
> -------------------------------------------------------------------------
> 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
>=20
|
|
From: Chris E. <chr...@gm...> - 2007-05-10 02:32:13
|
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
>
|
|
From: John v. S. <jc...@cs...> - 2007-05-10 08:40:19
|
Chris Eberz wrote: > > 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 BB chasing was causing this in my program, that is why I disabled it (and slowed it down even more :o) Put VG_(clo_vex_control).guest_chase_thresh = 0; in your code or just use the command line option --vex-guest-chase-thresh Cheers, |
|
From: John v. S. <jc...@cs...> - 2007-05-10 12:08:47
|
WARNING: This is going to be a large bunch of text ;-)
Josef Weidendorfer wrote:
> 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 something
> similar as you, but does not disable VEX optimizations.
I'm really interested in this! See below why I found it required to
disable the constant propagation.
>
> What are the scenarios where disabling this is necesssary?
>
When developing this, I've used a simple testcase. I would just create
an assembler function, so I could artificially create indirect calls and
jumps. The ASM file is directly below (NASM syntax)
segment .text
global f
global g
f:
push rbp
mov rbp, rsp
mov r11, g
call (r11)
leave
ret
g:
push rbp
mov rbp, rsp
jmp b
a:
leave
ret
b:
mov r11, 0x500000
add r11, 0x123456
mov r11, a
jmp (r11)
I call valgrind on this
valgrind --tool=lackey --trace-flags=11000000 --trace-notbelow=0
--vex-guest-chase-thresh=0 ./asm 2>asm.out
The relevant part of the valgrind output:
*Conversion of f to IR (up to the call instruction):*
0x400450: pushq %rbp
------ IMark(0x400450, 1) ------
t0 = GET:I64(40)
t1 = Sub64(GET:I64(32),0x8:I64)
PUT(32) = t1
STle(t1) = t0
0x400451: movq %rsp,%rbp
------ IMark(0x400451, 3) ------
PUT(168) = 0x400451:I64
PUT(40) = GET:I64(32)
0x400454: movq $4195424, %r11
------ IMark(0x400454, 7) ------
PUT(168) = 0x400454:I64
PUT(88) = 0x400460:I64
0x40045B: call* %r11
------ IMark(0x40045B, 3) ------
PUT(168) = 0x40045B:I64
t2 = GET:I32(88)
t3 = GET:I64(88)
t4 = Sub64(GET:I64(32),0x8:I64)
PUT(32) = t4
STle(t4) = 0x40045E:I64
====== AbiHint(Sub64(t4,0x80:I64), 128) ======
goto {Call} t3
*IR of f after the first optimization (up to the call instruction):*
------ IMark(0x400450, 1) ------
t0 = GET:I64(40)
t6 = GET:I64(32)
t5 = Sub64(t6,0x8:I64)
PUT(32) = t5
STle(t5) = t0
------ IMark(0x400451, 3) ------
PUT(40) = t5
------ IMark(0x400454, 7) ------
PUT(88) = 0x400460:I64
------ IMark(0x40045B, 3) ------
PUT(168) = 0x40045B:I64
IR-NoOp
t8 = Sub64(t5,0x8:I64)
PUT(32) = t8
STle(t8) = 0x40045E:I64
t10 = Sub64(t8,0x80:I64)
====== AbiHint(t10, 128) ======
goto {Call} 0x400460:I64
So after the first optimization the the expression exprIsConst(
bbOut->next ) for this BB will be true and thus my code thinks it is a
direct call.
But I've just tried it out with a more realistic example (function
pointers in C)
#include <stdio.h>
#include <stdlib.h>
#include <inttypes.h>
int add4660( int x );
int higherOrder( int (*incrFunc) (int), int param );
int main( int argc, char** argv ) {
printf( "Result higherOrder : %d\n", higherOrder( &add4660, 1) );
return 0;
}
int higherOrder( int (*incrFunc) (int), int param ) {
return (*incrFunc)(param) + add4660(param);
}
int add4660( int x ) {
return x + 0x1234;
}
But then the call to (*incrFunc)(param) isn't a constant expression,
even if I enable BB-chasing, which will lead to a BB from the start of
main to the call to the dereferenced function pointer.
So basicly, it goes 'wrong' for the artificial case.
> Did you also disable BB chasing? AFAIK, chasing can remove direct jumps in the
> guest instruction stream when converting to IR. So any numbers about direct
> jumps go wrong.
>
Yes I did disable BB chasing. Basicly because I wanted all jumps at the
end of a BB, so I would only have to check that.
>
> 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.
I'm really not into other platforms than x86 or AMD64, so I didn't knew
that. Is there a fail proof way to determine if it a call in or return
in PPC?
Either way it is not really important for this tool. It is build to see
if a certain optimization in the compiler would lead to less indirect
jumps/calls.
>
> Josef
Thanks for your comments!
-- John
|
|
From: Julian S. <js...@ac...> - 2007-05-10 15:26:15
|
> So basicly, it goes 'wrong' for the artificial case. I don't think you can reliably establish what you want by looking at the post-optimisation IR. Whether or not bbOut->next is Iex_RdTmp or Iex_Const depends a lot on what the IR optimiser (iropt) was able to do. In your artificial example, you construct a value in a register and jump to that, but iropt folds the computation out so it looks like a direct jump at the IR level. Conversely, it could happen (maybe ..) that the program does a jump to a constant location, but CSEing of the IR causes bbOut->next to be an Iex_RdTmp. IR is designed to make explicit the program's semantics and allow easy optimisation and instrumentation. But it is not good for answering questions about the original instruction forms. There is a solution, though. Ignore all the IR except the IRStmt_IMarks. These tell you the start address of each instruction. Your instrumentation code can use that to read the instructions and detect for themselves the branches and branch kinds. This is not ideal, but in fact there are not many forms of branches (read guest-amd64/toIR.c) and so it is not so much work. Remember that you will quite often get a REX prefix in the range 0x40 .. 0x4F before the primary opcode. J |
|
From: Josef W. <Jos...@gm...> - 2007-05-10 17:07:10
|
On Thursday 10 May 2007, John van Schie wrote:
> Josef Weidendorfer wrote:
> > However, Julian just added a simple branch prediction simulation into cachegrind
> > (see SVN), and for distinguishing direct/indirect jumps, he does something
> > similar as you, but does not disable VEX optimizations.
> I'm really interested in this! See below why I found it required to
> disable the constant propagation.
Just check out the SVN version.
And thanks for the example. For the branch predictor simulation, IMHO
a misdetection of a indirect jump guest instruction as a direct jump
is not problematic. When constant propagation leads to such a misdetection,
the branch was very predictable, so it won't show up as a possible
time problem either way (which cachegrind is about).
However, for your use case, it would really be nice to note in IR via
some hint the exact branch kind of a guest instruction jump.
In callgrind, I have a similar problem: I have to disable
chasing, because it gets rid of the information whether a control
flow change inside of a SB is a boring jump or a call.
> But then the call to (*incrFunc)(param) isn't a constant expression,
> even if I enable BB-chasing, which will lead to a BB from the start of
> main to the call to the dereferenced function pointer.
As far as I understand this, it is because the function pointer is passed
as parameter via the stack, and once in memory, it never can be interpreted
by VEX as a constant.
> So basicly, it goes 'wrong' for the artificial case.
Yes, probably only for hand-crafted assembler.
> > 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.
> I'm really not into other platforms than x86 or AMD64, so I didn't knew
> that. Is there a fail proof way to determine if it a call in or return
> in PPC?
I am not really into PPC either.
But if you look at "bl" ("branch to link register"), this usually
should be a return, as LR usually stores return addresses with PPC.
Neverless, it also can be used as indirect jump, at least in some hand
crafted assembler. So this already is ambigous.
That is the reason why the call graphs produced by callgrind on PPC
are suboptimal :( Any help appreciated.
Josef
> Either way it is not really important for this tool. It is build to see
> if a certain optimization in the compiler would lead to less indirect
> jumps/calls.
>
> >
> > Josef
>
> Thanks for your comments!
>
> -- John
>
|
|
From: Nicholas N. <nj...@cs...> - 2007-05-10 22:51:00
|
On Thu, 10 May 2007, Josef Weidendorfer wrote: > And thanks for the example. For the branch predictor simulation, IMHO > a misdetection of a indirect jump guest instruction as a direct jump > is not problematic. When constant propagation leads to such a misdetection, > the branch was very predictable, so it won't show up as a possible > time problem either way (which cachegrind is about). I don't think I agree -- I'd much prefer it if the branch simulator was able to treat things as they were in the original code. That it currently doesn't (IIUC) is a significant shortcoming. Nick |
|
From: Josef W. <Jos...@gm...> - 2007-05-11 12:05:01
|
On Friday 11 May 2007, Nicholas Nethercote wrote: > On Thu, 10 May 2007, Josef Weidendorfer wrote: > > > And thanks for the example. For the branch predictor simulation, IMHO > > a misdetection of a indirect jump guest instruction as a direct jump > > is not problematic. When constant propagation leads to such a misdetection, > > the branch was very predictable, so it won't show up as a possible > > time problem either way (which cachegrind is about). > > I don't think I agree -- I'd much prefer it if the branch simulator was able > to treat things as they were in the original code. That it currently > doesn't (IIUC) is a significant shortcoming. Yes, of course. I just suspect that in this case the difference will not be much for the number of mispredictions. Josef > > Nick > |