|
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
>
|