This is the mail archive of the 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 8:17 PM, Alexandre Oliva <> wrote:
> On Nov 27, 2007, "Richard Guenther" <> wrote:
> > 2007-11-26  Alexandre Oliva  <>, Jan Hubicka  <>
> >         * 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.

I agree here.  I am currently evaluating what just reverting the following ...

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

... part of the patch does to the memory usage regression.  This part doesn't
fix a regression and a better implementation strathegy for fixing the underlying
problem should be used IMHO.  To recap, the problem is that while using
UIDs for decls gives you a unique identifier, iterating over a hashtable where
you hash on UIDs doesn't give you a stable order (but it depends on the size
of the hashtable and so for example changes once that is re-allocated).  For
one commonly used hashtable (the referenced_vars hashtable) I have posted
patches that I consider only appropriate for stage1.


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