Re: [tree-ssa] cfg.texi needs reviewing by a native speaker (Was: Re: "Documentation by paper")

[Jan Hubicka <jh at suse dot cz>]

> In message <20040209220612.GN20341@kam.mff.cuni.cz>, Jan Hubicka writes:
>  >> In message <20040209173849.GD12597@atrey.karlin.mff.cuni.cz>, Jan Hubicka w
>  >rite
>  >> s:
>  >>  >> In message <20040205231458.GC10518@kam.mff.cuni.cz>, Jan Hubicka writes
>  >:
>  >>  >>  >Also since you seem to be poking around the stuff in tree-ssa, you sh
>  >all
>  >>  >>  >be warned that the predictions are poorer than on mainline.
>  >>  >> I'm not terribly concerned about the predictions at the tree level at t
>  >his
>  >>  >> time.
>  >>  >Predictions on RTL level are broken too.
>  >> As I'm all to aware.  This messes up both register allocation and block
>  >> placement, which ultimately result in a 10% performance loss in perl.
>  >> 
>  >> So exactly what problems are you aware of?
>  >
>  >I tried to explain that in previous mail, but in more detail.
>  >
>  >The problem are the highlevel prediction heuristics. GCC has some code
>  >that notice that "goto" is usually not executed, return -1 is usually
>  >error state or loops formed by continue statement are usually not
>  >looping as many times as real loops. These are messed up completely by
>  >gimplification process.
> I wouldn't go that far.

I didn't meant that the RTL predictions are broken, just the highlevel
ones, that are simply missing on branch.
> 
> For example, the code to predict goto as not being executed simply doesn't
> exist in the tree-ssa code.  I'll also note that adding this predictor
> actually makes things significantly worse for perl.

Isn't it because the GOTOs are inserted/removed randomly during
gimplification/optimization so this info simply don't make sense
anymore?  It works only when GOTOs writen by users are predicted by this
way.

In the mainline summary for perl 0.3% of executed branches with 80%
accuracy, so it shall not make things worse, but probably not
significantly better either.
> 
> And it would seem to me that the looping predictors should be independent
> of the gimplification code.  Can you explain why they are not?

They are using the continue hints and also know that copied loop headers
> 
> 
>  >I plan to fix that by making profile survive down to the RTL and do
>  >these predictions on tree only by NOTE_INSN_PREDICTION equivalent passed
>  >down by simplifier.
> I can see how this could be helpful, but I don't think that is the 
> underlying real issue here.
> 
> Q. Do we have any code which allows me to instrument the code, run the
> test, then compare the predicted results with the actual results?

See analyze_brprob script in the  contrib directory.  It has some info
about use in it and you can see data collected by profiled tester at
http://www.suse.de/~aj/SPEC  (see result files and analyze_brprob
archive)

Honza
> 
> jeff
>