Re: [tree-ssa] where to fix this?

[law at redhat dot com]

In message <Pine.LNX.4.44.0401060906440.28220-100000@www.eyesopen.com>, Roger S
ayle writes:
 >
 >On Mon, 5 Jan 2004 law@redhat.com wrote:
 >> ie, if I have something like
 >>
 >> x = (type) y;
 >>
 >> If we can prove that the typecast is useless, then we can enter x = y into
 >> the const_and_copies table and copy propagate y into the uses of x.  Often
 >> this also makes "x" go away completely.
 >
 >Wouldn't it be reasonable to record "(type) y" in the table, and then
 >propagate "(type) y" into all the uses of x, so that x can go away?
When presented with a NOP_EXPR which is not a useless conversion (say
for example it changes the width or signedness of an object) we record
the NOP_EXPR in the available expression table.  This allows us to remove
redundant NOP_EXPRs.  When we find a useless type conversion we also
record an equivalence in the const_and_copies table.

To illustrate the differences let's consider the following:

  x = NOP_EXPR (a)
  z = PLUS_EXPR (x, b);
  y = NOP_EXPR (a);


Let's first make the assumption that the NOP_EXPR does something like
change the signedness or width of the type.  In this case the NOP_EXPR
is not useless so we enter x = NOP_EXPR (a) into the available expression
table and would transform the above code into:

  x = NOP_EXPR (a)
  z = PLUS_EXPR (x, b);
  y = x;


Note we can not replace the "x" inside the PLUS_EXPR with NOP_EXPR (a) since
that would create non-gimple code, nor can we replace the "x" inside the
PLUS_EXPR with "a" since that would create a PLUS_EXPR with mismatched
types (and mis-matched in a bad way since width and signedness and
widths of "a" and "x" are different).


Now given the same pseudo code let's assume the NOP_EXPR is a useless
type conversion (does not change width or signedness):

  x = NOP_EXPR (a)
  z = PLUS_EXPR (x, b);
  y = NOP_EXPR (a);

We would record the equivalence x = a into the const_and_copies table and
record x = NOP_EXPR (a) into the available expression table.  After
optimization we would get:

  /* First statement deleted */
  z = PLUS_EXPR (a, b);		/* Via copy propagation */
  y = a;			/* Via redundant expression elimination and
				   copy propagation.  */






 >If we store the equivalence that x is "256", tree-ssa must also need
 >to record that the 256 is a signed vs. unsigned char vs. integer.
 >Therefore, isn't the const_and_copies table implicitly typed?
Correct it is implicitly typed, though it's not "strongly" typed since we
do allow certain mismatches in the type when we know that a conversion
between the types is useless.




jeff