This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] Fix gcc.dg/tree-ssa/20030530-2.c
- From: law at redhat dot com
- To: Diego Novillo <dnovillo at redhat dot com>
- Cc: Jason Merrill <jason at redhat dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 11 Jun 2003 12:21:11 -0600
- Subject: Re: [tree-ssa] Fix gcc.dg/tree-ssa/20030530-2.c
- Reply-to: law at redhat dot com
In message <firstname.lastname@example.org>, Diego Novillo wr
>On Wed, 2003-06-11 at 10:27, email@example.com wrote:
>> In message <firstname.lastname@example.org>, Jason Merrill writ
>> >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
>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?