Re: Profile information - CFG

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

On 10/5/07, Hariharan Sandanagobalane <hariharans@picochip.com> wrote:
>
>
> 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

Gcc expects the profile to be "flow consistent".
i.e. at any basic block, the sum of execution count of all incoming edges
have to be equal to that of outgoing edges.

I have a patch adding a new option to tolerate inconsistency
but it will have to wait for stage1 opening in 4.4.
-- 
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";