This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] Reenable LOOP_HEADER prediction
- From: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
- To: Daniel Berlin <dberlin at dberlin dot org>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, gcc-patches at gcc dot gnu dot org
- Date: Fri, 8 Apr 2005 10:53:10 +0200
- Subject: Re: [patch] Reenable LOOP_HEADER prediction
- References: <20050329131217.GA909@atrey.karlin.mff.cuni.cz> <20050407174810.GA7329@atrey.karlin.mff.cuni.cz> <1112896998.4686.69.camel@linux.site>
Hello,
> > > the predictor telling that the copied condition for the first iteration
> > > of loop is usually true became unused when loop header copying on
> > > rtl was removed. This patch makes tree level header copying to use
> > > it instead.
> >
> > Perhaps it would make more sense to reorder branch prediction and header
> > copying in order to allow it to take profile into account (and restrict
> > duplication in cold regilapons).
>
> I was going to point out (sometime soon :P) that we completely funkify
> the cfg doing header copying at times.
> I've got some nice .dot files that show we turned a simple nested loop
> into something we have significant trouble doing anything useful with
> because -ch changed it in a way that significantly changed the dominance
> structure in bad ways,
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);
}
> I was going to suggest we possibly move tree ch to sometime after high
> level loop opts,
I would suggest rather moving the high level loop opts sometime earlier
in the compilation.
Zdenek