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


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.  I however do not understand fully what is happening in this
testcase; the cfg is directly after .ch pass, or after some jump threading?
Could you send me the source file?

Zdenek


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