|
|
> Hello,
>
> > > > > 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.
>
> umm, nice. This cannot happen currently, just with your improvements to
> alias analysis of arrays, I assume? The consequences of our insane
> system of representation of results of alias analysis still surprise me
> sometimes :-)
>
> Zdenek
>
You keep saying things like "our current alias system representation is
insane", but you offer no constructive solutions.
Considering that the majority of our optimizations want to know, at a glance,
which loads/stores could possibly affect each other,
other than linking together these loads and stores through some manner (which
is what we do, and runs into the same problems no
matter how you link them together), and possibly providing a further
disambiguator for the links, which is the current and future plans,
what is your solution?
What do you think a "sane" alias representation looks like?
Just alias sets that you have to query for every load and load or load and
store pair you want to know about?
Such a scheme is pretty computationally expensive for optimizations to use to
the same level they use the current information.
|
|