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

[Jan Hubicka]

> In message <20040209223920.GP20341@kam.mff.cuni.cz>, Jan Hubicka writes:
>  >> 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.
> No, the code doesn't exist at all.  

I do get this :)
> 
> And if you insert it (carefully making sure that it only applies to user
> written gotos) then it still loses badly.  I haven't investigated why.

How did you get the trick?
The high level predictions needs to be lowered before CFG is cleaned up
and optimized in general, so if we do some pretty aggressive
optimizations before doing so, we can expect surprises.
It don't lose on mainline at all (I dimply recall that perl has been one
of benchmarks benefiting a lot from highlevel predictors, but it is long
ago and my memory is biassed)
But probably we need to analyze_brprob both mainline and tree-ssa to see
how scores looks like.  Perhaps just editing predictors.def and feeding
in the tree-ssa values will make scores better.
I will try to do so soon, but it will take day or two.
> 
>  >> 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 hint
> True, but we should be able to do something that is very similar (though 
> not exact) using the loop discovery and analysis code.

No you can't.  We do use loop discovery for heuristics where it apply,
but we can't here.  The loops formed by continue looks just like inner
loop in the CFG, but they are not.
Users usually write loop when it loops often and use continue to deal
with not-so-common scenarios.
> 
>  > and also know that copied loop headers
> Well, the tree-ssa branch copies loop headers quite effectivel now.

Yes and it still use the old code that does:
                      predict_insn_def (copy, PRED_LOOP_HEADER, TAKEN);
so it is recorded that unlike normal conditionals, this conditional will
usually be true.  I guess current tree-ssa is on the safe ground here.
Zdenek mentioned this to be one of problems when you move to new loop
copying that can't pass this info around.  It can be one of reasons why
moving the loop header copying around from RTLopt branch broke things
even more.
> 
> However, we don't create preheaders, which is a problem unto itself, but
> which as far as I can tell doesn't make a difference on the prediction
> problems.

Yes, that can only block loop.

Honza