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


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

> 2007-11-26  Alexandre Oliva  <aoliva@redhat.com>, Jan Hubicka  <jh@suse.cz>

>         * tree-ssa-live.c (remove_unused_scope_block_p): Drop
>         declarations and blocks only after inlining.  Check that
>         non-empty blocks are not dropped.
>         * tree-inline.c (expand_call_inline): Check that functions are
>         not inlined too late.

> there is a 50% increase in memory consumption and a 5% increase in
> compile-time for tramp3d.

For the record, two points:

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.

2. this patch delays the garbage-collection of some declarations after
inlining, to preserve decl UIDs in sync with and without debug
information.  I personally think that keeping decl UIDs is sync is a
very desirable property, and it's been quite useful for my recent
debugging efforts, but there are other ways to do this than keeping
declarations around just so that they can be cloned at the right time.
This particular fix should not make any difference if you're compiling
with -g, except where bug 1. incorrectly dropped entire blocks.

> I don't think this is acceptable.  Please revert the patch given that we are
> late in stage3.

I don't think letting -g or -g0 affect the executable code output by
the compiler is acceptable.  Reverting this patch would bring back the
regression in this regard, that was introduced on July 24, 2007.  So,
shall I revert both, or is the bug that caused us to unintentionally
drop a lot of information, thereby exaggerating the memory savings
that could be accomplished through the patch, going to trample a
fundamental design principle of GCC, not to mention the ability for
GCC to stand a chance of generating debug information for the
unintentionally-discarded information?

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