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 <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


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