This is the mail archive of the gcc-patches@gcc.gnu.org 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: [patch] Reenable LOOP_HEADER prediction


On Mon, 2005-04-11 at 11:12 +0200, Zdenek Dvorak wrote:
> Hello,
> 
> > > this should not happen. Currently, we only copy the && type chains of
> > > conditions, so you will not get anything more complicated then
> > > (equivalent of)
> > > 
> > > if (cond1 && cond2 && ... && condk)
> > >   {
> > >     do
> > >       {
> > >       }
> > >       while (cond1 && ... && condk);
> > >   }
> > 
> > Yes, but look at what it does to the CFG. 
> > I've attached two .dot files.
> > 
> > In the original, the block labeled 6 dominates the block labeled 2.
> > 
> > In the copy header version, because of the header copying, we end up
> > with a jump into the latch of the inner loop (the 3->12->2 path).
> > 
> > As a result, the block labeled 8 (which is the equivalent of 6 in the
> > original) no longer dominates block 2 because there is a path to it that
> > does not go through 8.
> 
> bb 8 does not correspond to bb 6 of the original, as far as I
> can tell.

It does, actually.

>   I however do not understand fully what is happening in this
> testcase; the cfg is directly after .ch pass, or after some jump threading?
Directly after ch pass in both cases.

> Could you send me the source file?

Sure, sent privately.

> 
> Zdenek


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