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 10/11/07, Alexandre Oliva <> wrote:
> >> I did this, but then I wonder...  How come the differences in decl
> >> uids arise from inlining of removed variables, if the patch was
> >> supposed to take effect only after inlining?
> > cfun->after_inline is set after fixup_cfg [...]
> > On mainline fixup_cfg is executed after apply_inline
> Indeed.
> >> If it is, then the test is meaningless.  The problem arises when we
> >> change the declarations in a function's logical blocks and then inline
> >> into others.
> >> What am I missing?
> That remove_unused_locals() was called by other post-pass TODOs, and
> that it would remove blocks that didn't contain any sub-blocks but
> that did contain declarations.  This caused variables only referenced
> in debug stmts to be wiped away too early.
> This alternate patch arranges for such blocks to not be deleted before
> inlining.  I'm not entirely sure removing them too early might
> possibly result in changes to the generated code, but I can't think of
> a case in which it would, with the current (trunk) debug info
> infrastructure.
> Thoughts?
> Here's the patch I'm testing now.

This doesn't change the amount of scope blocks we remove, just the point in
time, right?  (That is, you mainly assert that we don't remove scopes with

I'm worried that delaying deletion of scope blocks until after final
inlining will
increase peak memory usage as quite possibly the most savings currently
occur during early optimization.

Btw, did you analyze why

+              /* Removing declarations before inlining is going to affect
+                 DECL_UID that in turn is going to affect hashtables and
+                 code generation.  */
+              || !cfun->after_inlining)

removing declarations causes DECL_UID differences?  We don't re-use UIDs,
so this should be a no-op.  The only thing is that some algorithms walk the
referenced_vars hash-table and the order of this walk depends on the hash-table
size - but this should be really fixed in a different way (by removing
walks).  But maybe the DECL_UID problem is a different one?


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