scheduling vs lexical scopes

[Jason Merrill]

>>>>> "Richard" == Richard Henderson <rth@redhat.com> writes:

> The reason the origin doesn't have a die is that the origin was never
> emitted.  It wasn't emitted because the lexical block containing the
> origin was removed.  The lexical block was removed because (1) if-conversion
> managed to transform this function into a single basic block and
> (2) scheduling doesn't know what to do with BLOCK_BEG/END notes,
> and so re-emits them _all_ at the beginning of the block and (3)
> remove_unnecessary_notes removes lexical blocks that contain no
> real instructions.

The fix for this is to emit the abstract function before any optimization
is done.  That's what debug_hooks->outlining_inline_function is for.  I
suppose we need to add such a call to expand_body if the function is
inline.  Does the attached untested patch do the trick?

> Now, I also consider it a Bad Thing that any time scheduling is
> enabled for a function that has one basic block, we'll never be 
> able to see any local variables.

Yes.  This has annoyed me for a while.

> Solving this problem for real is hard.  We'd have to remember
> which instruction belonged to which lexical block, then regenerate
> a modified block tree based on the final schedule.  For extra
> points, figure out which instructions make no visible changes
> to user variables and consider them part of no lexical block
> so that scheduling is less likely to fragment a lexical block
> into thousands of little pieces.

The block tree wouldn't necessarily need to change; dwarf3 supports
discontiguous ranges.

Handling the trivial case should be a big improvement, though.

Jason

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-patch
Size: 1106 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20011228/8cd67eff/attachment.bin>