On Nov 26, 2007 7:57 AM, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> On Nov 24, 2007, "Richard Guenther" <[EMAIL PROTECTED]> wrote:
>
> > No, hashing is fine, but doing walks over a hashtable when your algorithm
> > depends on ordering is not.
>
> Point.
>
> > I have patches to fix the instance of walking over all referenced
> > vars. Which is in the case of UIDs using bitmaps and a walk over a
> > bitmap (which ensures walks in UID order).
>
> Why is such memory and CPU overhead better than avoiding the
> divergence of UIDs in the first place?
Actually my patches should be an overall memory savings. But, as you (and
me and others) look at bugs that happen because of UID divergence, it is
easier to use UIDs in a way that guarantees that generated code does not
change in such cases. Otherwise what's the point in using UIDs? If you
later do hashtable walks anyway you can hash on the pointer as well.
So, IMHO an algorithm should produce the same result if for an ordered set
of UIDs M { u1, u2, u3 } instead an ordered set M' { u1', u2', u3' } is used
where element correspondence is u1 : u1', u2 : u2', u3 : u3' independent
on the actual values uN or differences between values uN - uM.
Anything else is a bug. And compensating for those bugs in other places
by trying to preserve the exact values of UIDs is broken (and in this case,
as it delays memory optimization, actually bad).
Just my few euro-cents,
Richard.
