Re: Patch to block removal optimization

[Jason Merrill <jason at cygnus dot com>]

>>>>> Mark Mitchell <mark@codesourcery.com> writes:

 >   3) We don't try to remove blocks in final if we've done insn
 >      scheduling, since that moves block notes around arbitrarily;
 >      otherwise, we end up throwing away information for code that wasn't
 >      deleted at all.  Perhaps we should fix the scheduler so that block 
 >      notes are preserved better...

 > I'm a little bit confused by this bit.  On the one hand, it's
 > depressing, since -O2 -g is precisely the case that benefited most
 > from this: that's when we get all kinds of massive inlining, and lots
 > of code disappears, and we end up with lots of empty blocks.

Well, yes; when you pack all the notes together at the start of the basic
block, it looks like a bunch of empty blocks.  So the debugging info
shrinks because we don't know what code goes with what blocks.  Kind of a
Pyrrhic optimization...

 > In addition, I don't understand what good it does to have block
 > information output if the blocks are empty -- even if its the
 > scheduler's fault for making them so.  In other words, if, in the end,
 > we have:

 >   NOTE_INSN_BLOCK_BEG
 >   NOTE_INSN_BLOCK_END

 > what good does it do to output block data for that?  There are no
 > points in the debugger when you can print the value of the local
 > variables in there anyhow -- you're never in their scope.

Hmm, good point.  It seems that the reason this change was useful is that
the optimization was removing the outermost block of a function (the one
with __FUNCTION__ et al), which is always in scope.  I'll change it to test
that instead.

Jason