This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

> In message <>, Jan Hubicka writes:
>  >> In message <>, Jan Hubicka w
>  >rite
>  >> s:
>  >>  >> In message <>, 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

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  (see result files and analyze_brprob

> jeff

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]