Re: insertion of profiling code

[Jan Hubicka <jh at suse dot cz>]

> 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