Re: Continue stmt branch prediction

["Richard Guenther" <richard dot guenther at gmail dot com>]

On Wed, Mar 19, 2008 at 12:20 PM, Jan Hubicka <jh@suse.cz> wrote:
>
> > On Wed, Mar 19, 2008 at 11:52 AM, Jan Hubicka <jh@suse.cz> wrote:
>  > > > Hi,
>  > >  >
>  > >  > This patch may have caused
>  > >  >
>  > >  > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35636
>  > >
>  > >  Yes, the testcase needs adjusting (with PREDICT_EXPR sitting in, there
>  > >  are no longer perfectly nested loops, but a butterfly CFG).  I will look
>  > >  into it.
>  >
>  > PREDICT_EXPRs should not cause such effect (I still think they are
>  > ugly, but you made your point that BB or edge flags won't work).
>
>  If you have
>
>   loopback:
>     if (test1)
>       goto loopback;
>     if (test2)
>       goto loopback;
>
>  You have two perfectly nested loops.  Now
>
>   loopback:
>     if (test1)
>       {
>         somecode;
>         goto loopback;
>       }
>     somecode;
>     if (test2)
>       goto loopback;
>
>  You have two sibbling loops sharing header block.  The testcase is about
>  how loop infrastructure disambiguate the first case.  With predict_expr
>  in, we handle prediction more realistically (realizing that the test1 is
>  probably not closing loop construct since it comes from continue), but
>  disambiguation does not happen.
>
>  I will look into the other two cases tested by testcase but I think they
>  are same.  I think it is best to convert the inner loop into do-while
>  so it will still test the same.

Can you also split the testcase so the counters do not get (falsely) added?

Thanks,
Richard.