This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Continue stmt branch prediction
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.