This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] Decompose gimplify_expr
- From: Richard Guenther <rguenther at suse dot de>
- To: Steven Bosscher <stevenb at suse dot de>
- Cc: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>,gcc-patches at gcc dot gnu dot org, Daniel Berlin <dberlin at dberlin dot org>,Diego Novillo <dnovillo at redhat dot com>,Mark Mitchell <mark at codesourcery dot com>,Geoffrey Keating <geoffk at apple dot com>
- Date: Wed, 3 Aug 2005 11:49:14 +0200 (CEST)
- Subject: Re: [patch] Decompose gimplify_expr
- References: <20050722234109.GB23954@atrey.karlin.mff.cuni.cz><200508031126.18667.stevenb@suse.de> <20050803093249.GC29641@atrey.karlin.mff.cuni.cz><200508031138.58310.stevenb@suse.de>
On Wed, 3 Aug 2005, Steven Bosscher wrote:
> On Wednesday 03 August 2005 11:32, Zdenek Dvorak wrote:
> > Hello,
> >
> > > > > > In any case, I don't intend to implement any complicated
> > > > > > optimizations. I definitely will avoid any "special case handling";
> > > > > > if the optimization is too complicated, it is hardly worth doing
> > > > > > at the expansion time. I will be considering only simple
> > > > > > optimizations like unreachable code removal and constant
> > > > > > propagation that have a good chance to be very useful and save
> > > > > > significant amount of memory and compile time (especially on code
> > > > > > that uses macros a lot).\
> > > > >
> > > > > I will simply note that we have *already* run into issues because
> > > > > things like "constant propagation" were added to cleanup_cfg. (It
> > > > > ends up causing us to need to update ssa in some cases that it
> > > > > doesn't do, and shouldn't have to, since it's a fricking cfg cleanup
> > > > > pass)
> > > >
> > > > constant propagation is not performed anywhere in cfg cleanup.
> > >
> > > Constant propagation is performed in tree_merge_blocks when the PHI
> > > argument is a constant. IIRC Richard Guenther had an example of this
> > > actually happening in one of his test cases.
> >
> > OK, I forgot on this. Nevertheless, the constant propagation itself of
> > course does not cause need to update SSA;
>
> It does in Richi's case because ARRAY_REF<array, ssa_name> does not need
> SFTs, but ARRAY_REF<array,constant> does if the constant is smaller than
> the threshold he has for structure alias analysis for arrays.
> (I guess Richard can explain it best himself, so he's in the CC: now.)
Ok, I digged out a tree-dump after the fix, cunroll causes the problem
for the simple testcase
int x[2];
void foo(void)
{
int i;
for (i=0; i<2; ++i)
x[i] = i;
}
and we end up with (correctly)
foo ()
{
unsigned int ivtmp.29;
int pretmp.28;
int i;
int i.0;
<bb 0>:
# SFT.2_16 = V_MUST_DEF <SFT.2_5>;
x[0] = 0;
i_19 = 1;
ivtmp.29_20 = 1;
Invalid sum of incoming frequencies 5000, should be 10000
# ivtmp.29_2 = PHI <ivtmp.29_20(0)>;
# SFT.2_15 = PHI <SFT.2_16(0)>;
# SFT.1_14 = PHI <SFT.1_6(0)>;
# i_13 = PHI <i_19(0)>;
<L0>:;
# SFT.1_8 = V_MAY_DEF <SFT.1_14>;
# SFT.2_9 = V_MAY_DEF <SFT.2_15>;
x[i_13] = i_13;
i_10 = i_13 + 1;
ivtmp.29_3 = ivtmp.29_2 - 1;
return;
}
where the bug was that we had
<bb 0>:
# SFT.2_16 = V_MUST_DEF <SFT.2>;
x[0] = 0;
instead (or using an SSA name before it's definition - I don't
remember exactly, and I don't have a broken compiler lying around
anymore).
Richard.