Re: [Valgrind-developers] cachegrind and vex-chase

[Josef W. <Jos...@gm...>]

Am 23.06.2016 um 14:30 schrieb Christian Borntraeger:
> On 06/23/2016 02:21 PM, Josef Weidendorfer wrote:
>>>
>>> br       %r14
>>>               ------ IMark(0x800000DC, 2, 0) ------
>>>               PUT(336) = GET:I64(304)
>>>               PUT(336) = GET:I64(336); exit-Return
>>
>> How can the translation to VEX see that this is a Return?
>> Is %r14 expected to save the return address according to the ABI?
>
> Its tricky. There are no explicit return opcodes, but abi requires to have the
> return address as r14 on function entry.
> Of course gcc is free to shuffle things around in that function, so you can
> see all kind of registers for return,e.g. a br %r4 at the end of the function. when
> gcc spilled the r14 content on the stack and loaded the return into r4 before jumping
> back.

He. And cachegrind's branch simulator relies on the information: for 
returns, no
simulation is done, as it is assumed that branch prediction for returns 
always is correct.

On the other hand, a return address stack predictor in hardware probably 
also would need
to rely an that information. This may be enough motivation for a 
compiler to mostly use
"br %r14" as return instruction (?)

This actually is similar to x86: compilers could produce "push/ret" 
pairs as jumps, or
"call next; next: pop" to find out the PC address, but this is bad as it 
confuses the
return address stack prediction and slows down code...

Josef