> On 06/02/14 10:17, Dehao Chen wrote: > >We need to rebuild frequency after vrp, otherwise the following code > >in tree-ssa-threadupdate.c will make the frequency larger than > >upper-bound. > > > > /* Excessive jump threading may make frequencies large enough so > > the computation overflows. */ > > if (rd->dup_blocks[0]->frequency < BB_FREQ_MAX * 2) > > rd->dup_blocks[0]->frequency += EDGE_FREQUENCY (e); > > > >This is referring to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61384 > Can you try this with Teresa's revamping of the jump threading > frequency updates? It's still in my queue of things to review. > > Fixing this stuff in the updater would be better than rebuilding the > frequencies, IMHO.
Agreed. However one of problems is that the frequencies after VRP may be unfixable. If i.e. you have if (a) prob 20 else prob 80 if (a) prob 50 else prob 50 that can easily happen if the second conditional was more convoluted earlier in the optimization queue. We may track when this change and ask for frequency rebuild, but issue is that I am not completely sure if that is going to give us consistently more reliable profiles than without: the problem is that branch probabilities themselves may be misupdated by earlier passes. It may be interesting to do some analysis how well estimated profile corelate with measured profile thorough the optimization. The problem above would be less troublesome if we jump threaded at least some cases pre-branch prediction. It is one of reasions why I think it would be cool to do jump threading in early opts, too, at least in a lightweidt form. Now when VRP is able to annotate SSA names, VRP results could feed loop estimation analysis for i.e. get upper bound on iterations of: if (a<50) for (i=0;i<a;i++) that can in turn improve branch prediction. Also we can feed the ranges into ipa-cp and get ipa-cp to propagate ranges rather than constants. This will get us free non-NULL propagation. IPA-inline's predicates can take use of value ranges because they record conditionals and also the results can be fed back to post-IPA VRP (by setting value ranges of default def SSA names of the parmeters) The down side is, of course, that VRP is considered expensive. Honza > > Jeff