Re: Put scope blocks on a diet

["Richard Guenther" <richard dot guenther at gmail dot com>]

On Nov 27, 2007 11:56 PM, Alexandre Oliva <aoliva@redhat.com> wrote:
> On Nov 27, 2007, "Richard Guenther" <richard.guenther@gmail.com> wrote:
>
> > I agree here.  I am currently evaluating what just reverting the following ...
>
> >> 2. this patch delays the garbage-collection of some declarations after
> >> inlining,
>
> > ... part of the patch does to the memory usage regression.
>
> If you're compiling with -g, it won't do anything at all, for the
> !cfun->after_inlining is never even reached when debug_info_level >=
> DINFO_LEVEL_NORMAL.

I am talking about non-debug builds.  Yes, debug builds take a lot of
memory for tramp3d - a different issue that is worth addressing.

> Also, please don't call it a memory usage regression.  It's offensive.
> If a patch unintentionally dropped entire basic blocks went in and
> remained unfixed for months, would the fix that stops them from being
> dropped be regarded as a regression in memory usage?  This is
> ridiculous!

We would have noticed such a patch because we have a quite
extensive testsuite which tests what we seem to care most about.  You
could call it unfortunate that there is no test for the debuginfo part
that Honzas patch broke.  I could call it co-incidence.

> Let's please revert the patch that introduced the bug in the first
> place.  Then we can make an assessment of how much the memory
> optimization patch actually gets us without anyone being confused by
> the distortions caused by the bug in the patch.

?  So you mean comparing the current state with the !inline_completed
part removed to a version that doesn't remove unused scope blocks at all?
That is, what remains in memory savings?

> > This part doesn't fix a regression
>
> I don't understand how you got this mistaken impression.  Without this
> part of the patch, or something equivalent, the regression in the
> property that -g and -g0 emit the same code, introduced by Honza's
> initial patch, remains.  This fundamental property held before his
> patch, and it stopped holding afterwards.
>
> Do we consciously want to break this for GCC 4.3?

This particular part of the patch is just a workaround, and as you don't
have a testcase that breaks (apart from make bootstrap-debug) I cannot
qualify the importance of this regression.  Nevertheless memory-usage
for non-debug builds of applications are an existing issue.

I have a technically more sound patch (those were already posted as
queued for 4.4), and I am going to see if they fix the make bootstra-debug
regression.  So if you consider that regression important enough I'd rather
go with a real fix than a workaround with the memory penalty.  But let
me do the math and verification first.

> Also, considering how much scope information that patch causes us to
> unintentionally discard, do we consciously want to introduce such a
> major debug information regression in GCC 4.3, even with -O0?

I am not proposing to revert this part of the patch.  Please don't repeatedly
say so.

Richard.