Re: Put scope blocks on a diet

["Richard Guenther" <richard dot guenther at gmail dot com>]

On Nov 28, 2007 7:48 PM, Mark Mitchell <mark@codesourcery.com> wrote:
> Richard Guenther wrote:
>
> >> I never said it wasn't.  I just don't think it justifies breaking the
> >> -g/-g0 principle.
> >
> > Well, if we want to make that priciple "absolut"
>
> To make sure we're all talking about the same thing, the principle I'm
> referring to is that the instruction sequence generated for "-O2" and
> "-g -O2" be identical, or, more generally, that adding or removing "-g"
> to any command line not change the instruction sequence.
>
> That principle *is* absolute.  It has been for a long time.  I remember
> fixing bugs like this many years ago.  (A frequent cause used to be not
> remembering to skip NOTEs in the RTL stream, which would only be present
> with debugging turned on.)  This is an important promise that we make to
> users so that they can turn on -g to help figure out what's wrong with
> optimized code.

Right, I agree here.

> > the only sane way to
> > implement it is to just always follow the same path during compilation
> > (that is, do as if -g was enabled) and only at the point of debug output
> > do nothing.
>
> That would certainly fix it, but I don't think it's the only feasible
> way.  Modulo the occasional bug, we've been able to make this work for a
> long time without doing this.  I agree that if your solution were the
> only feasible approach we might have to make a tough decision (because
> of the cost of building up debug information), but, fortunately, I don't
> think that's the only feasible approach, so I don't think we have to
> make that choice.

The difference I want to make here is whether we want to accumulate fixes
(or hacks, dependent on how you see them) or if we really want to analyze
what causes the divergence.  At some point it may be better for maintainance
reasons to not make -g vs -g0 different (apart from output).

> > Yes and no.  Code generated shouldn't depend on varying UIDs.  In
> > principle bootstrap comparison should survive even if we did
> >
> >     DECL_UID (t) = next_decl_uid;
> >     next_decl_uid += random() % 13;
> >
> > anything else I consider a bug in how we use DECL_UIDs.
>
> I don't think that's been true historically.

Historically?  Ok, I'm new enough to gcc to not remember ;)

> IIRC, we've considered
> DECL_UIDs to be acceptable for use as hash/sort keys, even though we
> didn't want to use pointers.  (Pointers, of course, can differ from run
> to run with address-space randomization -- but, in the old days, the
> biggest problem was that they differed across hosts.)  I think that
> means that, in the past, DECL_UIDs must been the same between  -O2 and
> -g -O2 builds.

As far as I would say we use DECL_UIDs because you can establish an
ordering between UIDs while you cannot do so with pointers.  If you hash
either of them to implement set or map datastructures they are not different.
The difference is in how you can iterate in a reproducible way over a
set of them.  With UIDs because you have a ordering, you can iterate in
a defined ordering.  With pointers this is not possible.  So if you have an
algorithm whose result depends on the order of its inputs, then you better
define the ordering you prefer - which you can only fulfil if you have input
that can be sorted in any way.  Thus we use UIDs.  Now if we iterate over
a _hashtable_ (even if we hashed UIDs), your hashtable element ordering
does not map to a stable ordering of UIDs.

> We could weaken our assumptions, as you suggest, so that only the
> relative ordering of DECL_UIDs matters.  And, if that allows us to save
> a lot of memory, then that might be a better solution than trying to
> make DECL_UIDs the same between debug and non-debug builds.

Any ordering of UIDs only depends on "relative" ordering.

> Can we find the places that are walking the hash table and have them
> collect the declarations first, sort them by DECL_UID, and then walk the
> sorted array?  Or, use a splay tree instead of a hash table, since splay
> trees already have the property that walking the tree will always go in
> sorted order?  (Splay trees are of course O(log n) for most operations,
> whereas hashtables are O(1), ignoring resizing costs.)

Yes, I have done so for referenced_vars by using a bitmap indexed by UID.
Which is both space-efficient and fast in average (though O(n) in theory).
But this is not appropriate for stage3.

I think we need to be more careful in how we use UIDs - they are not in
itself a thing that leads to less problems.  And identifying the remaining
problematic cases is work.  Papering over the issue by disabling "optimizations"
for the non-debug case is bad IMHO, unless we want to unify the debug/non-debug
paths in general.

Thanks,
Richard.