This is the mail archive of the 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: [RFC] tree-ssa-ccp.c: Propagate even more ADDR_EXPRs.

> One difference would be that forwprop cares about the number of
> immediate uses regardless of whether an ADDR_EXPR is invariant or not,
> whereas CCP cares only about invariants and propagates them as far as
> possible.
It's actually quite easy to change forwprop.c to propagate to
multiple uses (that's how I had originally written the code).  The
reason it doesn't propagate to multiple uses is because doing so
generally creates worse code.

Consider propagating &a->b->c->d into multiple uses.  The net result
is actually _worse_ code.  Basically it would be un-doing redundancy

> One could argue that if we do this optimization in CCP, we may be able
> to eliminate a comparison of two ADDR_EXPRs like so
> struct f {
>   int i;
> };
> void
> foo (void)
> {
>   struct f a;
>   struct f *p;
>   int *q, *r;
>   a.i = 1;
>   p = &a;
>   q = &p->i;
>   r = &p->i;
>   if (q != r)
>     link_error ();
> }
> but that would be extremely rare, I'd say.
And the &p->i should have been a common subexpression and we
should have trivially determined that  q == r.

What's far more interesting is to look at something like
  p = &a->b->c->d
  q = *p->a[0];
  r = *p->a[1];

Which actually does happen in practice.  If you propagate the
ADDR_EXPR for p you generate significantly worse code.


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