Re: [tree-ssa] DCE fixes

[Daniel Berlin <dberlin at dberlin dot org>]

> > 2 - points to type with no variable instance -  aliasing.
> >   given:
> >      x->y->t = 1;
> >   we get something like:
> > 
> >      t1=x->y
> >      t2=y1->t
> >      *t3=1
> > 
> >   and with no actual variable of y2->t, aliasing currently indicates that
> >   *t3 isn't aliased with aything, so it looks like an unneeded store to a local
> >   and removes it along with all feeding statements.

This is fixed by component_ref refs.

Diego, for may aliasing, do i want to check just component_ref's with 
an indirect_ref as it's first part (IE a->b), or is it 
component_ref's with indirect_ref's anywhere in them (ie a->b.c) 
that we need to heck for aliasing?

> > 
> > 3 - assignment aliasing.
> >   char *p = buf + 125
> > 
> >   p and buf are not aliased, so all *p stores are consideredstores to locals
> >   serving no purpose, and so are removed.
> > 
> > 4 - aliasing is non-associative.
> >   *x alaises *p,
> >   *p aliases *z
> >   *x currently doesn't have *z as an alias.
> > 
> All these issues should be trivial with points-to analysis.

Not to disagree that PTA makes it trivial, but may aliasing *is* 
non-associative.
Just because *x may alias *p, and *p may alias *z, does *not* imply that 
*x may alias *z.
Try:
" x = p;
  x = q;
  p = z;"
Here x may alias p, p may alias z. x will never alias z (and we won't say 
it will). 

So your problem lies elsewhere.


>  Dan,
> how long do you think it would take to get a bootstrapping
> compiler with -ftree-points-to=steen?  

AS I mentioned, it's patented, so i'd rather us bootstrap with andersen's 
on, since i'll likely kill off steen's.
Also realize we check the PTA last, so if other stuff is claiming they 
don't alias, we'll never query PTA results.

>I tried today and it fails building print-rtl1.o with stage1/xgcc.
I think i fixed this problem already, as i can bootstrap with it on in my 
tree.


> 
> The tree-alias-* code seems to have lots of debugging output as
> well.  I guess it needs a bit of cleanup?
Nah, just change the #define's at the top to 0, rather than 1.
:)
> 
> 
> > 5 - Null statements terminate looping through a block.
> >   when statements are removed, they are replaced with a common null_statement 
> >   node.  gsi_step_bb() uses bb_for_stmt() to determine which block the current
> >   stmt is in, so we can never iterate past a deleted stmt.
> > 
> We could do the TF_STMT_DELETED idea.  The call to remove_stmt
> could mark them and then after DCE we could commit all the
> deletions.
> 
> > 6 - var-args sometimes generate odd looking instructions such as 
> >   ap = ap which have unadvertised side-effects. It looks like they are 2
> >   different 'ap's, and perhaps the var-arg builtin it is feeding is refering
> >   to the wrong 'ap'. When this stmt is deleted, we fail to generate some 
> >   addressing instructions which cause a few failures.
> > 
> Blech.  I guess we should mark varargs nodes non-gimple :(
> 
> > Here's the DCE patch. Comments? OK to commit on the branch?
> > 
> The patch looks OK to me.  Let's get it in so it helps fixing the
> infrastructure bugs you found.
> 
> 
> Diego.
>