This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Put scope blocks on a diet


Hi,

> 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

We however know we can fit all the relevant information into debug
section of tramp3d object file and that is a lot smaller than the
footprints of our in-memory representation. So making our in-memory
representation more similar to dwarf would be way to get memory to very
acceptable levels.  This is motivation of the proposed plan of not
duplicating decls and instead of looking them up in dwarf2out.

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

Alternative might be to enable this in some of our periodic testers.  If
this property does not tend to break all the time, I think it might be
enough testing without having signififcant degradation in our regular
testing cycles.  If we find this to break regularly, we can make
debugbootstrap a default. 

Debugbootstrap is good concept IMO and we should have it tested
regularly either in tester or by default.

I should also note that -fprofile-generate/-fprofile-use is another case
where we need compiler stable.  To large extend this is same problem (ie
in memory representation is slightly different in both runs, we still
need same decisions to given point of compilation).  I spent a lot of
hours tracking down divergences in compiler showing as profile mismatch,
hopefully this will also get caught more easilly with debug info testing.

Honza
> 
> > (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}


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]