Re: bb and loop profiling (was: [PATCH] sparc64-linux multilibs])

[Dan Nicolaescu <dann at ics dot uci dot edu>]

[trimmed the CC list and moved the discussion here from gcc-patches]

Richard Henderson <rth@cygnus.com> writes:

  > On Tue, Dec 07, 1999 at 02:06:09PM -0800, Dan Nicolaescu wrote:
  > > Some of the __bb_* functions are not allowed to change the state of
  > > the processor, if they use they use the app-regs then the
  > > MACHINE_SAVE_STATE macro hould save those registers too.
  > 
  > The __bb functions should be abandoned entirely.  The entire
  > approach use by -a and -ax is fundamentally flawed.

Do you want to get rid of them? I can certainly provide a patch that
does that, it will remove a couple of thousands of lines of code... 

  > Use -fprofile-arcs instead.

That you said this I looked at the code and saw that -a[x] and
-fprofile-arcs use the same data structures, but a different approach,
before I thought they were doing the same thing... 

I wish I knew this a year ago when I implemented some profiling code
for loops, add a call to a function at the beginning and at the end of
a loop.
The parameters for those functions were setup using the basic-block
profiling information. 

The problem with this is that it was a hack, I did it in final.c, the
idea is to look for LOOP_* notes and insert the code in the right
place. That proved to be a mess because of the difficulty to find out
all the exit points from a loop... 
It was a pain to get this working... 

I also added 2 flags: -aL and -al to insert loop profiling code on all
loops or only for the innermost ones, respectively. 


SUN's compiler has something like that when using the option -Zlp, and
then you can profile the loops using "looptool"

Maybe something like this is useful to more people...

How hard is it to find out what arcs are entry or exit points for
loops?  Is that information available? If it is, it should not
be too hard to add this kind of loop instrumentation.

--dan