Re: Put scope blocks on a diet

[Mark Mitchell <mark at codesourcery dot com>]

Alexandre Oliva wrote:
> On Nov 28, 2007, Mark Mitchell <mark@codesourcery.com> wrote:
> 
>> True -- but it is consistent across runs and across hosts.  Unless the
>> UIDs vary when you add -g, which, empirically, they do.
> 
> For the record, before the July 2[46] patch, they didn't. 

That's an important fact.  Given that, it's certainly not surprising
that we have algorithms that previously generated the same code with and
without -g, but now differ.

It sounds like we have three choices:

1. Revert the July patches and declare that (for now) DECL_UIDs must not
be influenced by -g.  Pros: -g doesn't affect generated code.  Cons:
compiler uses more memory than it does now, though no more than 4.2.

2. Accept that (for now) -g may affect generated code.  Pros: compiler
users less memory.  Cons: -g affects generated code.

3. Do something that makes us depend, at most, on DECL_UID order -- but
not on exact values.  Pros: -g doesn't affect generated code, compiler
uses less memory.  Cons: have to do something hard.

Is that right?  Nobody's going to like either (1) or (2) -- but as RM,
if I have to choose, I'm probably going to pick (1) because I think the
-g principle is critical.

Richard has done some version of (3) that he thinks isn't suitable for
Stage 3.  Richard, can you say what's risky about your patch?  Given
that nobody is going to like either choice (1) or choice (2), is your
patch worth considering?

Have we figured out how many places in the compiler are actually hashing
based on DECL_UID?  If it's not many, then we can wrap those hash tables
so that the order in which we walk them is stabilized.  We don't
necessarily have to do the prettiest thing right now; we just have to
find some way of containing the damage.  A basic grep is only showing
about 10 places that look like hashes of DECL_UID, so doing an audit of
these to see which of these hash tables are walked, and then interposing
a sort phase before the walk, certainly seems tractable.

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