Re: [tree-ssa] Fix gcc.dg/tree-ssa/20030530-2.c

[law at redhat dot com]

In message <1055357012.824.73.camel@frodo.toronto.redhat.com>, Diego Novillo wr
ites:
 >Say B is aliased to {MT.1, MT.2} and C is aliased to {MT.3}.  The method
 >I have in mind would create an array of VUSES for each operant of the
 >PLUS_EXPR, so instead of having a vuse_ops(stmt) with a single array
 >with the 3 VUSEs for MT.1, MT.2 and MT.3, you would have two arrays, one
 >for 1st operand of the PLUS_EXPR and another one for the 2nd operand of
 >the PLUS_EXPR.  So that, for the statement 'A = B + C' you would have:
 >
 >vuse_ops (TREE_OPERAND (PLUS_EXPR, 0)) == {MT.1, MT.2}	<-- vuses of B
 >vuse_ops (TREE_OPERAND (PLUS_EXPR, 1)) == {MT.3}	<-- vuses of C
 >
 >Similarly, for 'Z = C + B':
 >
 >vuse_ops (TREE_OPERAND (PLUS_EXPR, 0)) == {MT.3}	<-- vuses of C
 >vuse_ops (TREE_OPERAND (PLUS_EXPR, 1)) == {MT.1, MT.2}	<-- vuses of B
 >
 >So, in this case, you always see the VUSEs in the same order as they are
 >referenced in the expression.  It's deterministic and can be mapped to
 >the original operand.  I don't know whether it's useful for what you
 >have in mind, though.
Right, but what guarantees that MT.1 and MT.2 always appear in the same
order?

Regardless, I don't need to associate the vuses with any particular
operand, I just need them to appear in a consistent order.

 >> Can you refresh my memory as to what objects can appear in the VUSE
 >> array?  Just SSA_NAME, or do we potentially have things like
 >> COMPONENT_REF, INDIRECT_REF, VAR_REF, etc?
 >> 
 >Just SSA_NAMEs.  VUSEs are typically emitted for aliases.  But we also
 >use VUSE/VDEFs for aggregate types.
Then sorting them ought to be easy and reasonably fast.

jeff