Re: Profile information - CFG

["Seongbae Park (박성배, 朴成培)" <seongbae dot park at gmail dot com>]

On 9/27/07, Hariharan Sandanagobalane <hariharans@picochip.com> wrote:
> Hello,
> I am implementing support for PBO on picochip port of GCC (not yet
> submitted to mainline).
>
> I see that GCC generates 2 files, xx.gcno and xx.gcda, containing the
> profile information, the former containing the flow graph
> information(compile-time) and later containing the edge profile
> information(run-time). The CFG information seems to be getting emitted
> quite early in the compilation process(pass_tree_profile). Is the
> instrumentation also done at this time? If it is, as later phases change

Yes.

> CFG, how is the instrumentation code sanity maintained? If it isnt, How

Instrumentation code sanity is naturally maintained
since those are global load/stores. The compiler transformations naturally
preserve the original semantic of the input
and since profile counters are global variables,
update to those are preserved to provide what unoptimized code would do.

> would you correlate the CFG in gcno file to the actual CFG at
> execution(that produces the gcda file)?

> As for our port's case, we are already able to generate profile
> information using our simulator/hardware, and it is not-too-difficult
> for me to format that information into .gcno and .gcda files. But, i
> guess the CFG that i would have at runtime would be quite different from
> the CFG at initial phases of compilation (even at same optimization
> level). Any suggestions on this? Would i be better off keeping the gcno
> file that GCC generates, try to match the runtime-CFG to the one on the
> gcno file and then write gcda file accordingly?

Not only better off, you *need* to provide information that matches
what's in gcno, otherwise gcc can't read that gcda nor use it.
How you match gcno is a different problem
- there's no guarantee that you'll be able to recover
enough information from the output assembly of gcc,
because without instrumentation, gcc can optimize away the control flow.

pass_tree_profile is when both the instrumentation (with -fprofile-generate)
and reading of the profile data (with -fprofile-use) are done.
The CFG has to remain the same between generate and use
 - otherwise the compiler isn't able to use the profile data.

Seongbae