Re: More on compile performance of Linux kernels in mainline gcc

[Jan Hubicka <hubicka at ucw dot cz>]

> Jan Hubicka <hubicka@ucw.cz> writes:
> 
> >> Andi Kleen <ak@suse.de> writes:
> >> 
> >> > This is an addendum for the numbers for linux kernel compiling
> >> > on x86-64 I posted some days ago. gcc tested is the same (041029)
> >> > on the same machine with the same kernel tree/configuration.
> >> 
> >> I can't comment on most of this, but:
> >> 
> >> > Looks like the likely/unlikely split is not very effective,
> >> > there are a lot of hot unlikely hits. 
> >> 
> >> That logic has known bugs.  You could try disabling it
> >
> > I didn't look too closely on Caroline's work, but what bugs do you
> > know of?
> 
> I don't actually know anything specific.
> 
> It occurs to me that one possible explanation for Andi's observations
> is that the partitioner decided that the *whole function* belonged in
> the cold section.  This is a silly thing for it to do, but not out of
> the question.

The hot/cold paritioning heuristics declare basic block hot iff it
executes at least 10000 fewer times than the most hot basic block in
program, this seemed quite conservative at first glance...

So either the summary or BB count is wrong or we really spend
significant fraction of time in basic blocks not having this property
because we do have too many of them.
To fix that we probably would need to introduce new summary information
that will paritition out hottest basic block up to given overall
threshold and save the count of the coldest one in the set...

I wonder if anyone knows what other compilers are doing here...

Honza
> 
> zw