Re: Put scope blocks on a diet

[Alexandre Oliva <aoliva at redhat dot com>]

On Nov 28, 2007, "Richard Guenther" <richard.guenther@gmail.com> wrote:

> It depends.  We may come to the point that enabling -g doesn't consume
> measurably more ressources.  Which would be indeed nice.

Hey, but that's easy!  We just make sure compiling without -g wastes
lots of resources.  Then, -g won't consume more ;-)


Seriously, there's no other way -g won't consume measurably more
resources.  There's no way you can fit more information in the same
space as less information, unless the less-information case is highly
redundant, which indicates a poor job in packing less information.  If
less information was stored as efficiently as stand-alone as with the
rest of the information that makes up more, then it would certainly
take up less resources.  This is information theory 101.  (Shall we
discuss infinite compression algorithms and perpetual motion engines
now? :-)


In order to generate debug information, it's not enough to keep only
the information needed to output executable code.  You have to keep a
mapping from source concepts to the executable code.  This takes up
resources.  And the more you optimize, the more complex this mapping
becomes, and therefore the more additional resources you need to
represent them, both in the internal representation and in the debug
information output.

> That is absolutely a goal we should try to fulfil.  Though it may not matter
> that much in practice as we are either good enough, or in cases where
> it matters you build with -g, ship stripped binaries and have the debug
> information extracted from the build and saved in -debuginfo packages.

Weren't we having a discussion just now about the importance of saving
memory for builds without -g?  I guess it does matter in practice,
after all ;-)

>> bootstrap-debug.  And the nice thing is that it doesn't only exercise
>> more paths in the compiler, it is also faster than a full bootstrap
>> with debug information enabled (the current default).  We could easily
>> suggest it as the default testing procedure, at least on platforms on
>> which it works, for I honestly don't know how portable bit-per-bit
>> comparison of stripped objects is.

> Well, if we want not to break the -g vs. -g0 property then we should
> enable this by default for regular bootstrap

+1

> (maybe somehow distinguish debug comparison failures from code
> comparison failures).

There's no such thing as debug comparison failures.  bootstrap-debug
doesn't compare debug information.  It strips out debug information
and compares only the actual code.

bootstrap-debug builds stage2 without -g (or, actually, with -g0,
which is like no -g, if someone doesn't have that clear) and stage3
with -g, and makes sure the generated code is the same for both.

> Just to compare -g vs. -g0 dumps?

Yes.  That makes finding out where a bootstrap-debug failure comes
from.

> But yes, less divergence in the dumps would be nice, and you can
> produce that with simple scripts that rip out UIDs of temporaries.

This doesn't help you locate the divergencies where they matter,
because you've thrown away the baby along with the bathtub water.  The
divergencies are precisely where the differences in generated code
have come from, in several of the cases I've debugged over the past
couple of months in the VTA branch.

So, yes, as I pointed out before, the usefulness of this property is
quite limited, but it's also cheap to achieve with the placeholders I
proposed.  It's even cheaper than the additional bitmaps you propose,
my intuition tells me.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}