Re: [tree-profiling] Fix return predictors

[Jan Hubicka <jh at suse dot cz>]

> On Sun, 2004-08-08 at 15:34, Jan Hubicka wrote:
> > Hi,
> > this patch should fix the return predictors after Richard's change to
> > commonize RETURN_STMT.
> > 
> > Bootstrapped/regtested i686-pc-gnu-linux
> > 
> > Honza
> > 
> > 2004-08-08  Jan Hubicka  <jh@suse.cz>
> > 	* predict.c (apply_return_prediction): New function.
> > 	(tree_bb_level_predictions): Use apply_return_prediction; kill old
> > 	return prediction code.
> > 	(tree_estimate_probability): Fix early return prediction.
> It ought to be interesting to see if this helps the lousy predictions
> we're getting from early return.  Here's some data from compiling
> some testcodes (from GCC itself):
> 
> early return       13211  10.7%   3.22% /  99.67%   3997952937   4.9%
It is, of course, supposed to do precisely that ;)  They perform
relatively well (except the problem that I got const return predictor
reversed - I will fix it soonish)

negative return                 244   0.3%  97.61% /  99.94% 47941718   0.1%
const return                    478   0.6%  32.95% /  70.13% 107027177   0.3%
null return                     451   0.6%  93.44% /  94.91% 115026414   0.3%

The early return has always been poor predictor (tought it works better
than nothing), it's success rate on SPEC is about 60% so the branch
prediction combining heeristics don't take it very seriously into
account anyway.  It has improved from 57% to 63% by this patch, the old
RTL based predictor did 62% on SPEC so we are basically in the same
shape.  If you point me out what code particularly did you compiled, I
might look into it and see if we can di significnatly better on it too.

The situation is not quite easy tought as the new predictors are
predicting on trees, while mainlne does predict on RTL.  The reason why
I didn't merged the tree predicting code is that it produced worse SPEC
numbers and we need to kill old loop to preserve the profile from trees
down.
On tree profiloing branch we now get better SPEC scores, faster
compilation even with the loop disabled, so I will start merging
remaining neccesary infrastructure bits at the end of week and in the
case loop won't be replaced for 3.5, we can simply reconstruct the
profile estimate from REG_BR_PROB notes (I tried that on tree profiling
branch and it works just as it is written now).

There is not terribly much to merge into mainline (I already merged
almost everything that didn't hurt the SPECS) so I hope it will be
possible to finish it for 3.5.

Honza
> 
> Jeff
> 
>