Re: [RFC Patch, Aarch64] : Macros for profile code generation to enable gprof support

[Matthew Gretton-Dann <matthew dot gretton-dann at linaro dot org>]

Marcus,

On 9 August 2013 18:17, Marcus Shawcroft <marcus.shawcroft@arm.com> wrote:
> On 03/08/13 19:01, Venkataramanan Kumar wrote:
>
>
>> 2013-08-02  Venkataramanan Kumar  <venkataramanan.kumar@linaro.org>
>>
>>           * config/aarch64/aarch64.h (MCOUNT_NAME): Define.
>>             (NO_PROFILE_COUNTERS): Likewise.
>>             (PROFILE_HOOK): Likewise.
>>             (FUNCTION_PROFILER): Likewise.
>>          *  config/aarch64/aarch64.c (aarch64_function_profiler): Remove.
>>             .
>>
>> regards,
>> Venkat.
>>
>
> Hi Venkat,
>
> Looking at the various other ports it looks that the majority choose to use
> FUNCTION_PROFILER_HOOK rather than PROFILE_HOOK.
>
> Using PROFILE_HOOK to inject a regular call to to _mcount() means that all
> arguments passed in registers in every function will be spilled and reloaded
> because the _mcount call will kill the caller save registers.
>
> Using the FUNCTION_PROFILER_HOOK and taking care not to kill the caller save
> registers would be less invasive.  The LR argument to _mcount would need to
> be passed in a temporary register, say x9 and _mcount would also need to
> ensure caller save registers are saved and restored.
>
> The latter seems to be a better option to me, is there compelling reason to
> choose PROFILE_HOOK over FUNCTION_PROFILER_HOOK ??

(I think you mean FUNCTION_PROFILER rather than FUNCTION_PROFILER_HOOK
in all the above.)

Using either PROFILE_HOOK or FUNCTION_PROFILER results in a call chain
that looks like the following (assuming the C Library is glibc):

 Function -> _mcount -> _mcount_internal.

Where _mcount_internal is the C function that does the real work and
is provided in glibc.  Importantly this means that _mcount_internal
follows the normal ABI - so we have to save the caller saved registers
somewhere.

Using FUNCTION_PROFILER requires us to write assembler which saves and
restores all caller saved registers every time it is called, and
requires (as you say) a special ABI.  This means _mcount ends up being
a piece of assembly that saves all caller-saved registers (i.e.
parameter-passing & temporary registers) and then makes the call to
_mcount internal before restoring everything on _mcount's return.

Using PROFILE_HOOK will cause the compiler to do all the heavy
lifting, and it will do the minimum required (for example with a
function with one parameter it will only save and restore x0).
_mcount in this case can be a simple function that sets up some
parameters and calls _mcount_internal (or even _mcount could just
alias _mcount_internal).

As to which of PROFILE_HOOK or FUNCTION_PROFILER are "the right way"
(TM) - I don't know - the documentation isn't very clear at all.
PROFILE_HOOK was introduced to support profiling for AIX 4.3.
http://gcc.gnu.org/ml/gcc-patches/2000-12/msg00580.html is the initial
patch, with a reworked patch here:
http://gcc.gnu.org/ml/gcc-patches/2001-02/msg00112.html. The final
commit happening on 2001-02-05.  The patch was introduced because it
was impossible to make FUNCTION_PROFILER work for AIX 4.3 and so a new
hook that worked earlier in the compiler was needed.  There doesn't
seem to have been a discussion about preferring one form over the
other.

In conclusion - I prefer the PROFILE_HOOK method because it makes the
compiler do all the work, and results in less impact on stack usage
and performance.  FUNCTION_PROFILER may impact the code generated by
the compiler less and produce a smaller overall image - but I'm not
sure that's more beneficial.

Thanks,

Matt


-- 
Matthew Gretton-Dann
Linaro Toolchain Working Group
matthew.gretton-dann@linaro.org