Re: fbranch-probabilities bug

[Hariharan <hariharans at picochip dot com>]

Seongbae Park ??? ??? wrote:
> On Thu, Jan 8, 2009 at 10:11 AM, Hariharan <hariharans@picochip.com> wrote:
> > Hi Seongbae,
> > Does that mean that someone cant use the profile just to annotate branches
> > (and get better code by that), without having to get the additional baggage
> > of "unroll-loops", "peel-loops" etc?
>
> You can do that by selectively turning optimizations off (e.g.
> -fprofile-use -fno-unroll-loops -fno-peel-loops ).
>
> > In my case, i am interested in not bloating the code size, but get any
> > performance that is to be had from profiling. Is that possible?
> >
> > Note: My profile generate phase was also just -fprofile-arcs since i am not
> > interested in other kinds of profile.
>
> Have you measured the impact on the performance and the code size from
> using full -fprofile-generate/-fprofile-use ?

Well, No... I cannot. I have just about managed to get -fprofile-arcs 
and -fbranch-probabilities work with picochip. The code runs under a 
simulator and i have had to hack both GCC code and libgcov code to get 
the simulator output the profile in the format that would be acceptable 
to Gcc in the second run. Doing the same with the additional profiles is 
going to be a hard task.

Its a target that has MEM processor versions, which has 6KB (yes KB not 
MB or GB) Instruction memory, at best. So, you can understand why code 
size is very important to us.

Anyway, it looks to me that we might get very little performance benefit 
without bloating the code with PBO, so that makes it very unattractive 
for me to do anything along this line.

By the way, your changes to smoothen the profile information in GCC 4.4 
helped a lot. From where I had 13 profiling tests(drawn from GCC dejagnu 
testsuite) failing in GCC 4.3.2 with "corrupted profile info" messages, 
it got down to just one failure in GCC 4.4. Thanks for that.

Cheers
Hari

> If yes, and you have seen any performance degradation or unnecessary
> code bloat from other optimization,
> please file a bug.
> If not, then I'd say you probably want to try measuring it - in
> particular, value profiling has been
> becoming more and more useful. And in my experience, majority of the
> code size increase as well as the performance benefit
> with -fprofile-use comes from extra inlining (which -fprofile-arcs
> then -fbranch-probabilities also enable).
>
> Seongbae