Re: patch for support profiling for AIX 4.3

[Chandra Chavva <cchavva at cygnus dot com>]

On Thu, 14 Dec 2000, Richard Henderson wrote:

> On Mon, Dec 11, 2000 at 03:12:49PM -0800, Chandra Chavva wrote:
> > IBM AIX 4.3 does not support profiling. When AIX 4.3 tools are 
> > compiled with -p option, the compiler does not generate the correct code. 
> 
> No this is not ok.  You need to explain why the existing code in
> output_function_profiler case ABI_AIX is not correct.
> 
  The case ABI_AIX in output_function_profiler is done after the 
registers are allocated for a function call. This case is generating 
the following code at the begining of a function

  foo:

	prologue
        mr 30,3               r3 -> r30
        mr 29,4               r4 -> r29      -> r4 = 0 changing r29 = 0
        mr 28,5
        mr 27,6
        mr 26,7
        mr 25,8
        mr 24,9
        lwz 3,LPC..1(2)
        bl .__mcount
        nop
              we need these insns because .__mcount uses parm regs (r3-r9).
        mr 3,30              r30 -> r3
        mr 4,29              r29 -> r4
        mr 5,28
        mr 6,27
        mr 7,26
        mr 8,25
        mr 9,24



   bar:
   
	r29 was used here
        bl	foo
        nop
	and the return value is compared with r29 and they 
will not be the same after the function call. 


This is happening only for IBM AIX4.3 target. My patch educated 
expand_function_call that a function foo is calling mcount.

Chandra


Here are some comments from Geoff Keating on this 

> firstly, remember we don't generally support profiling.
>
> We should still fix this.  The problem is that on AIX, emitting the
> profiling code is done in a complicated way and much too late in the
> compilation.  What it should do is emit a call to __mcount at the
> start of the function during the initial RTL generation.  Then the
> register allocator will automatically move registers around so that
> __mcount doesn't overwrite anything.
>
> Basically, this is an example of trying to do something complicated in
> a machine's backend, when it could be done much more easily with a
> little hook in the middle of the compiler.
>


> Even if it is then decided that the current code is hopelessly
> broken, the bulk of your patch is not required.  LTI_profile_mcount
> and all accompanying changes are not needed.  Further, if the old
> code is going to be obsoleted, it should be removed not disused.
> 
> 
> r~
>