This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


In message <1055353965.824.55.camel@frodo.toronto.redhat.com>, Diego Novillo wr
ites:
 >On Wed, 2003-06-11 at 10:27, law@redhat.com wrote:
 >> In message <wvlwufsg0fp.fsf@prospero.boston.redhat.com>, Jason Merrill writ
 >es:
 >>  >Do we need to worry about commutativity wrt the VUSEs, as well?
 >> Yes.  My plan is to sort the VUSE array (ugh).
 >> 
 >How about we tie the VUSEs to the actual sub-tree to which they're
 >related?
 >
 >A = B + C
 >
 >    ^
 >    |
 >    +-- VUSE1, VUSE2, VUSE3 ...
 >
 >Right now there is a single varray with all the VUSES, maybe we could
 >distribute those varrays into the sub-trees of the expression.
 >
 >Clearly, this needs more thought, as this would change we access the
 >virtual operands for a statement.
I don't see how this solves the problem, but maybe I'm being dense.  Do
we have anything which guarantees ordering within the subarray?  What
happens when I have A = B + C and Z = C + B?

My gut is telling me that we should bite the bullet and sort the
vuses based on some stable criteria.  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?

Jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]