On Tue, Jul 31, 2012 at 12:43 PM, Richard Guenther <richard.guent...@gmail.com> wrote: > On Tue, Jul 31, 2012 at 12:38 PM, Jan Hubicka <hubi...@ucw.cz> wrote: >>> On Tue, Jul 31, 2012 at 12:20 PM, Dehao Chen <de...@google.com> wrote: >>> > Are you suggesting a patch like this: >>> > >>> > Index: gcc/predict.c >>> > =================================================================== >>> > --- gcc/predict.c (revision 189835) >>> > +++ gcc/predict.c (working copy) >>> > @@ -1319,6 +1319,7 @@ >>> > tree loop_bound_var = NULL; >>> > tree loop_iv_base = NULL; >>> > gimple stmt = NULL; >>> > + int header_found = 0; >>> > >>> > exits = get_loop_exit_edges (loop); >>> > n_exits = VEC_length (edge, exits); >>> > @@ -1387,9 +1388,20 @@ >>> > >>> > bbs = get_loop_body (loop); >>> > >>> > + /* Loop branch heuristics - predict an edge back to a >>> > + loop's head as taken. */ >>> > + if (loop->latch && loop->latch->loop_father == loop) >>> >>> Hmm, so the issue is that loop->latch does not belong to loop? That looks >>> like a bogus loop structure. Indeed we have the loop header of the inner >>> loop as latch of the outer loop. It still looks ok to predict this as >>> unlikely >>> as the edge is not only the latch edge of the outer loop but also an exit >>> of the inner loop. >>> >>> Easier for profile would be to force canonicalization via >>> >>> loop_optimizer_init (LOOPS_NORMAL); >>> >>> instead of >>> >>> loop_optimizer_init (0); >>> if (dump_file && (dump_flags & TDF_DETAILS)) >>> flow_loops_dump (dump_file, NULL, 0); >>> >>> mark_irreducible_loops (); >> >> Yeah, this may also work. The reason it is not done is that >> 1) it seemed expensive to force CFG changes just to compute profile decade >> ago >> 2) cfgcleanup afterwards will anyway remove the headers again. >> So I originally hoped to do the right thing without normalization. > > Ok ... then you should pass AVOID_CFG_MODIFICATIONS instead. And be > prepared for odd situations like this ;)
In which case the bug looks like that we predict the inner loop exit as unlikely but not the outer loop exit which should compensate things and not end up predicting zero iterations? That is, all patches seem to paper over a real issue elsewhere. Richard. >> Honza
