insertion of profiling code

insertion of profiling code

[Kenneth Zadeck]

When I was working on the detecting const and pure functions, I ran 
across the following comments in passes.c:


  /* It may make more sense to mark constant functions after dead code is
     eliminated by life_analysis, but we need to do it early, as 
-fprofile-arcs
     may insert code making function non-constant, but we still must 
consider
     it as constant, otherwise -fbranch-probabilities will not read data 
back.

     life_analysis rarely eliminates modification of external memory.

     FIXME: now with tree based profiling we are in the trap described above
     again.  It seems to be easiest to disable the optimization for time
     being before the problem is either solved by moving the transformation
     to the IPA level (we need the CFG for this) or the very early 
optimization
     passes are made to ignore the const/pure flags so code does not 
change.  */

Now that I am doing the detection of pure and const functions in the ipa 
pass there does appear to be the possibility of fixing this problem.  
(my code is still a secret, but I am planing to post a patch this 
weekend.) Unfortunately, my code still seems to do this detection too 
late since my analysis occurs over the cfg and the code appears to be 
being added when the cfg is being built.

The two possible solutions to this problem appear to be:
1) The addition of the profiling code can be decoupled from the creation 
of the cfg and could be added at any later pass where the cfg is still 
around.

2) Some annotation could be attached to the added code that I could 
teach my pass to ignore.

I am an advocate of the first plan.

Comments?

Kenny

Re: insertion of profiling code

[Jan Hubicka]

> When I was working on the detecting const and pure functions, I ran 
> across the following comments in passes.c:
> 
> 
>  /* It may make more sense to mark constant functions after dead code is
>     eliminated by life_analysis, but we need to do it early, as 
> -fprofile-arcs
>     may insert code making function non-constant, but we still must 
> consider
>     it as constant, otherwise -fbranch-probabilities will not read data 
> back.
> 
>     life_analysis rarely eliminates modification of external memory.
> 
>     FIXME: now with tree based profiling we are in the trap described above
>     again.  It seems to be easiest to disable the optimization for time
>     being before the problem is either solved by moving the transformation
>     to the IPA level (we need the CFG for this) or the very early 
> optimization
>     passes are made to ignore the const/pure flags so code does not 
> change.  */
> 
> Now that I am doing the detection of pure and const functions in the ipa 
> pass there does appear to be the possibility of fixing this problem.  

This is what I seriously hope for ;)
BTW I asked you about the profiling crash... don't worry about it as I
already found the problem (I think) in Steven's merge so I will fix it
tomorrow.  Also current branch has your IPA analysis disabled.  I fixed
them too to work on CFG during the flight...

> (my code is still a secret, but I am planing to post a patch this 
> weekend.) Unfortunately, my code still seems to do this detection too 
> late since my analysis occurs over the cfg and the code appears to be 
> being added when the cfg is being built.
> 
> The two possible solutions to this problem appear to be:
> 1) The addition of the profiling code can be decoupled from the creation 
> of the cfg and could be added at any later pass where the cfg is still 
> around.
> 
> 2) Some annotation could be attached to the added code that I could 
> teach my pass to ignore.
> 
> I am an advocate of the first plan.

Me too, and in the link time IPA we probably want to read the profile on
link time (as mentioned earlier by someone else, we want avoid user from
need to rebuild after profiling), so I guess I can just organize
profiling as little IPA pass even if it does quite little of ipaness.

But actually even in current scheme we don't have the problem, just it
is avoided the other way around - we first insert all the profiling code
(at analysis stage) and then start marking the const/pure functions (at
IPA stage) so the instrumentation is not influenced anyway.

Thanks for looking into this.
Honza
> 
> Comments?
> 
> Kenny