Put scope blocks on a diet

[Mark Mitchell]

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.

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

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

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.

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

> But surely you now won't make consistent DECL_UIDs in debug dump
> -g/-g0 a correctness issue?

Indeed not.  The content of the dumps isn't important, except in that it
helps us debug the compiler.  But, it is very important that "-g -O2"
and "-g" generate bit-for-bit identical instruction sequences.

Thanks,

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