Re: [tree-ssa] patch suggestion: def_op vs vdef_ops

[law at redhat dot com]

In message <Pine.LNX.4.44.0301291702460.25729-100000@nether.cs.uiuc.edu>, Jose 
Renau writes:
 >
 > When a variable has aliases, the variable itself and the aliases are
 >inserted in vdef_ops. When it does not have alias it is inserted in def_op.
Right.


 > The result is that in many cases (like in tree-ssa-dce.c) both need to be 
 >checked:
 >
 >  if (def_op (stmt) && need_to_preserve_store (*(def_op (stmt))))
 >    return true;
 >
 >  ops = vdef_ops (stmt);
 >  for (i = 0; ops && i < VARRAY_ACTIVE_SIZE (ops); i++)
 >    if (need_to_preserve_store (VDEF_RESULT (VARRAY_TREE (ops, i))))
 >      return true;
Almost. :-)


 > My suggestion is:
 >
 > -Always add to vdef_ops so that using only vdef_ops is enough in many
 >cases.
 >
 > -The destination variable is always inserted in def_op. Not only when it 
 >is a non-aliased scalar value.
 >
 > With that modification def_op would be a subset of vdef_ops. I can see
 >some cases (like in some of the transformations that I have) where it is
 >very interesting to know the variable modified, not the alias.
 >
 > Can someone enlightme with reasons for not doing it?
The idea was that if you didn't care about trying to optimize
memory references that you could just iterate over the true operands.
It also pretty closely matches what we found in other compilers when
we were researching the handling of memory operands in SSA form.

If you wanted to run ccp, dce, etc etc on memory operands, then you'd
iterate over both.

The decision would (of course) be controlled by a user switch :-)

We haven't got to a point where we're doing that, but that was the
rational behind that design.

jeff