This is the mail archive of the
gcc-patches@gcc.gnu.org
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 19:17:43 -0600
- Subject: Re: [tree-ssa] Fix gcc.dg/tree-ssa/20030530-2.c
- Reply-to: law at redhat dot com
In message <1055362533.824.77.camel@frodo.toronto.redhat.com>, Diego Novillo wr
ites:
>On Wed, 2003-06-11 at 15:19, law@redhat.com wrote:
>
>> >Heck, if we only have to deal with SSA_NAMEs, which are unique (right?),
>we
>> >can just sort by address.
>> Or their version #. Either way it's a simple comparison routine.
>>
>Oh, so you just want deterministic access. I thought you wanted to
>distinguish which VUSES where for which operand. In that case, sorting
>by VAR_DECL address might be better because we can insert them sorted as
>we build the voperands.
>
>If you sort by SSA version number, then you have to build the voperand
>array first and wait until after the SSA pass to re-sort each varray.
>
>Either way is fine with me, really.
I think it ultimately depends on the costs -- which in turn depend on the
size of the varrays and insertion patterns. Hmmm, actually, I think we
have to go with sorting by the VAR_DECL address since we need this info
during the rename into SSA process.
Of course, this could all be a non-issue. I haven't tried to measure how
often we're missing redundancies due to different hashes caused by different
ordering of vuse operands. It may be the case that it's so infrequent that
it's not worth the headache/overhead. It's on my todo list.
jeff