Re: (C++) tree inlining patch RFD

[Mark Mitchell <mark at codesourcery dot com>]

>>>>> "Jason" == Jason Merrill <jason@cygnus.com> writes:

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

    >> Your (partial) fix is probably an improvement: it's probably a
    >> good idea to walk the tree in forward-order.

    Jason> I'm uncomfortable with the order-dependency.  I find it odd
    Jason> that the logical scope surrounding the for-statement is
    Jason> represented by a SCOPE_STMT inside the first operand of the
    Jason> FOR_STMT.

That, however, is what we've always done, even before we had
SCOPE_STMTs; the SCOPE_STMTs are appearing exactly where
expand_start_bindings/expand_end_bindings calls appeared previously.

I think there's an inherent and natural order-dependency; given, say,
an IF_STMT, I think you would agree that the THEN_STMT block should
come before the ELSE_STMT block, right?

    >> I think the best fix might be to just do this:

    >> o When inlining, copy over the body of the function, as we do.
    >> Along the way remap SCOPE_STMT_BLOCKs to new equivalents, but
    >> do not worry about BLOCK_SUBBLOCKS or BLOCK_SUPERCONTEXT.  So,
    >> we'll have now a tree with SCOPE_STMTs for all the new BLOCKs,
    >> but the new BLOCKs will not be properly connected.

    >> o Run a post-pass, before giving the function to the back-end,
    >> that puts all the blocks into a tidy tree.  This should be
    >> easy; just run your forward-order walk_tree over the function
    >> body adding to the tree.

    Jason> I'm not sure how that would be an improvement.

Because the problem we're currently having is that we're trying to
maintain the BLOCK-tree on the fly.  What I proposed is essential what
the back-end use to do with integrate_decl_tree: first, copy the
inlined code (including a bunch of BLOCK notes, which are SCOPE_STMTs
in tree-land) and then patch in the copied block-tree.  Our problem is
that it's a little harder to patch in the copied block-tree, so I'm
suggesting we just wait on the patching until end-of-all-inlining, and
then do one big fixup.

The back-end wans the BLOCK_BEG/BLOCK_END notes emitted to match up
exactly with the BLOCK tree.  So, the algorithm I proposed ensures
that this will indeed happen.  In semantics.c we're going to walk the
statement-tree putting out block-notes for SCOPE_STMTs; if we walk in
that same order earlier, building the BLCOK tree, we'll be sure to
have things in sync.

Does it make sense now?

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com