This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Profile information - CFG




Seongbae Park (???, ???) wrote:
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.

Thanks for your help, seongbae.


I have managed to get the profile information formatted in the way .gcda would look. But, does GCC expect the profile to be accurate? Would it accept profile data that came out of sampling?

-Hari


Seongbae


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]