 |
| Prev-20 | Home | Next-20 |
| Prev-20 | Home | Next-20 |
| Prev- | Prev- | Gcc | Sep- | Next- | Next- |
| Subject: | Re: Profile information - CFG |
| Group: | Gcc |
| From: | Seongbae Park (¹Ú¼º¹è, ÚÓà÷ÛÆ) |
| Date: | 28 Sep 2007 |
On 9/27/07, Hariharan Sandanagobalane <hariharans> 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
| Prev- | Prev- | Gcc | Sep- | Next- | Next- |