I found that the optimization must be on in order to see the frequency.
Timothy
On 6/24/05, Liu Haibin <[EMAIL PROTECTED]> wrote:
> Then I think I shouldn't use -fprofile-arcs. The reason why I used
> -fprofile-arcs is when I debugged a program without any flags, I saw
> the frequency was zero. When I added this flag, I saw frequency with
> values.
>
> I checked the frequency after life_analysis and before
> combine_instructions. I used
>
> FOR_EACH_BB(bb) {
> // some code
> }
>
> and checked the bb->frequency.
>
> So now the question is how I can see the frequency without any flags.
> The following was the small program I used to check the frequency.
>
> int foo(int i)
> {
> if (i < 2)
> return 2;
> else
> return 0;
> }
> int main()
> {
> int i;
>
> i = 0;
> if (i < 100)
> i = 3;
> else
> i = foo(i);
>
> return 0;
> }
>
>
>
>
> On 6/24/05, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> > On Thu, 23 Jun 2005, Liu Haibin wrote:
> >
> > > Hi,
> > >
> > > I want to use profiling information. I know there're two relevent
> > > fields in each basic block, count and frequency. I want to use
> > > frequency because the compiled program is for another architecture so
> > > it cannot run on the host.
> >
> > Besides the fact that, as Zdenek hsa pointed out, this is not a useful
> > situation for -fprofile-arcs, ...
> > >
> > > My question is why it is so? I want to know the profiling info, but if
> > > profiling info I get is for another different structure of basic
> > > block, it's useless to me.
> > >
> >
> > This is because it's inserting profiling code.
> >
> > This isn't magic, it's inserting code to do the profiling, which
> > necessarily changes the basic blocks.
> > The profiling info you get is for the original set of basic blocks.
> >
> >
>
