This is the mail archive of the gcc-patches@gcc.gnu.org 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
elimination.



> 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.


Jeff


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