Re: [patch] Decompose gimplify_expr

[Richard Guenther <richard dot guenther at gmail dot com>]

On 8/3/05, Zdenek Dvorak <rakdver@atrey.karlin.mff.cuni.cz> 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; removal of the unreachable
> edges does.  So I still fail to see Daniel's point -- this trivial case
> of constant propagation in cfg cleanup does not cause any "corner cases
> in simple optimizations that nobody thinks about that bite us in the ass
> later".

A constant propagation into an ARRAY_REF like

 # i = PHI <0>
 # V_MAY_DEF <a.0_1>
 # V_MAY_DEF <a.1_1>
 a[i] = x;

causes

 # V_MUST_DEF <a.0>
 a[0] = x;

where a.0 is not in SSA form and needs to be renamed.

Richard.