Re: [patch] Fix tree-optimization/20139.

[Jeffrey A Law <law at redhat dot com>]

On Wed, 2005-02-23 at 12:43 -0500, Kazu Hirata wrote:
> Hi Jeff,
> 
> > FWIW, we might consider just folding any expression that is subject
> > to TER.  I've got a patch somewhere around here which does that.  
> > 
> > Mostly it seems to eliminate casts, but from time to time it finds
> > something it can zap in complex expressions.
> > 
> > Thoughts?
> 
> That would work, too.  Could you dig up your patch please?
That required some serious digging :-)

I think all I did was put in the appropriate call to fold_stmt
in rewrite_trees.   I suspect the code may have changed some, but
you can see what I was working with in this fragment from 
rewrite_trees:


          if (!remove)
            {
              FOR_EACH_SSA_DEF_OPERAND (def_p, stmt, iter, SSA_OP_DEF)
                {
                  if (replace_def_variable (map, def_p, NULL))
                    changed = true;

                  /* If both SSA_NAMEs coalesce to the same variable,
                     mark the now redundant copy for removal.  */
                  if (is_copy
                      && num_uses == 1
                      && (DEF_FROM_PTR (def_p) == USE_OP (uses, 0)))
                    remove = 1;
                }
              if (changed && !remove)
                {
                  modify_stmt (stmt);
                  fold_stmt (bsi_stmt_ptr (si));
                }
            }

> 
> The only thing I am worried about is its effect on compile-time
> performance.  Have you had a chance to take a look at that?  I suppose
> calling fold once for every statement or so shouldn't hurt too much.
I never really looked at it.  I was more interested in seeing what
folding opportunities were exposed by TER and whether or not it made
sense to beef up some optimizer earlier in the tree-ssa path.

Most of the stuff it found was useless casts.

Oh yea, to bootstrap we needed to remove a possibly bogus call to
STRIP_NOPS from maybe_fold_stmt_indirect.

Jeff