Put scope blocks on a diet

[Jan Hubicka]

> Alexandre Oliva wrote:
> 
> >> there is a 50% increase in memory consumption and a 5% increase in
> >> compile-time for tramp3d.
> 
> > For the record, two points:
> 
> Alexandre, please take the rhetoric down a notch.  I know you have
> strong feelings about this, but you're among friends. :-)
> 
> > 1. this patch prevents non-empty blocks with referenced variables from
> > being dropped.  This was a bug, and it may have given the impression
> > that the memory reductions achieved through the earlier, buggy patch
> > that IIRC went in on July 24 was correct.  But dropping too much
> > information was a mistake.  We could decide it's ok and desirable to
> > drop such information, but it has to be a conscious decision, not an
> > accidental fallout from a bug.
> 
> That certainly makes sense.  Do you have a URL for the July 24 patch?
> 
> Meanwhile, please revert your patch.  We don't want to oscillate too
> much.  Is there a PR for the problem that your patch fixed?  If not,
> please sure that there is one.

As original author of the diet path, I must say I am with Alexandre
here.  The patch to reduce memory usage on scope blocks was based on
some analysis of memory usage and it was shooting basically for removing
unneded blocks (empty/unreachable) with and without -g.  I added more
aggressive code to remove almost all scope blocks for compilation
without debugging since it seemed like cheap way to get that 50% memory
usage saving on tramp3d.

All earlier GCC releases would use more memory to represent debug info
than current mainline with Alexandre's patch so technically we are not
in regression land here.  Mainline GCC we still take care to remove
empty blocks, blocks that became unreachable and all block after
inlining, while earlier GCCs will keep all the data in memory.  We now
inline bit more because of IPA-SSA changes that is making some
difference, but it is not an uncontrolled explossion.

I agree with Alexandre that it is a bug to produce different code with
and without -g. I didn't originally think this side effect (that
dropping blocks would make inliner not produce duplicated DECLs that
will change DECL_UIDs that will make hashtables to diverge) and if I did
I would not do the optimization.

Of course we don't need all that memory to represent info that will end
up pretty small in DWARF file.  We ought to restructure the info so we
don't duplicate all the DECLs with each inline just to add simple
pointer to DWARF that given decl is duplicated.  I think inliner can
just copy the live declarations that needs to be output fully (ie have
registers assigned) and the "dead" declarations can be just looked up
via ABSTRACT_ORIGIN pointer of the scope block.  This is however might
be bit tricky to get right (I don't feel very confided in debug info
area).

I also believe that 50% of memory usage is extreme case, I know of no
other testcase (can construct artifical one easilly however), where we
would have similar difference.

Honza
> 
> > I don't think letting -g or -g0 affect the executable code output by
> > the compiler is acceptable.
> 
> I don't either.  But, we don't have agreement on how best to solve the
> problem.  So, let's a get PR open, which will help ensure we solve the
> problem before the release, and then let's talk about how we can solve it.
> 
> Thanks,
> 
> -- 
> Mark Mitchell
> CodeSourcery
> mark@codesourcery.com
> (650) 331-3385 x713