Re: Put scope blocks on a diet

[Mark Mitchell <mark at codesourcery dot com>]

Richard Guenther wrote:

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

Right, a priori, either approach seems plausible.  My guess is that in
practice the cost of accumulating all the debug information only to
throw it away is going to be too expensive, but I've been wrong plenty
of times before.

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

I think that's a good observation, but my impression was that the
motivation was actually that DECL_UIDs are consistent across hosts and
across runs.  In any case, both properties are useful.

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

True -- but it is consistent across runs and across hosts.  Unless the
UIDs vary when you add -g, which, empirically, they do.  I don't know if
that was always true (and we never noticed) or if this is a new
property.  (I've gotten a little lost on the actual technical details here.)

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

Perhaps not, but other fixes might be.  If that's the problematic table,
then replacing the walk function with a walk (to collect the nodes), a
qsort, and an iteration might be fine, and very contained.

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

I agree that we absolutely do not want to disable code-generation
optimizations for the non-debug case.  We also don't want to disable
compile-time optimizations, if we can help it, but we should be willing
to pay a little bit -- and no more -- of compile-time if absolutely
necessary.  (No, I don't have a concrete bounding of "a little bit"...)

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713