On Thu, Oct 04, 2012 at 09:42:59AM +0200, Richard Guenther wrote:
> This looks like the wrong place to fix things to me ... either we can
> fix this at the point we create the VAR_DECLs for the optimized away
> PARM_DECLs (or we should delay that until here?)
No, that is not possible. There is no other block they could be added
to (they are added to DECL_INITIAL block), and they definitely need to
be added there, they are needed for the more common case where it is not
inlined.
And in that case it is the right location, for non-inlined function
DECL_INITIAL block's BLOCK_VARS is added directly as children of the
DW_TAG_subprogram.
> or we fix it up
> in dwarf2out.c (how does this fix interact with stabs and the other
> debuginfo formats?
We can't do that either, dwarf2out doesn't have information whether blocks
are really used (as in, any insns/stmts mention that block in
INSN_BLOCK/gimple_block) or not, it is only correct to move the VAR_DECLs
with PARM_DECL DECL_ORIGIN (i.e. DW_TAG_formal_parameter) up if the outer
BLOCK is not referenced by any insn/stmt (i.e. if the ranges of the
inner block with the VAR_DECL and outer block are exactly the same).
If the outer block has range that is superset of the inner block's range,
then the move would invalidly say that the DW_TAG_formal_parameter
is available somewhere where it is not supposed to be available.
Initially I thought I'd do the moves in tree-ssa-live.c, in
remove_unused_scope_block_p it has information about what blocks are used
by any stmts and what are not. But it would be terribly expensive,
for each VAR_DECL in a block where its BLOCK_SUPERCONTEXT wasn't originally
TREE_USED before remove_unused_scope_block_p (and such blocks up to a
!TREE_USED inlined_function_outer_scope_p), it would need to search
all the BLOCK_SUPERCONTEXT BLOCK_VARS to see if the VAR_DECL isn't present
there as well, and only if not, move to the inlined_function_outer_scope_p
BLOCK.
Doing it in tree-inline.c is IMHO the right spot, it is the place that
creates the extra artificial BLOCK around the remapped DECL_INITIAL block
and puts function arguments there. At that point we know for sure that
the DECL_INITIAL block has the same ranges as the whole inline function,
and it is desirable to move all arguments to the outer block, not just
those that were still present in DECL_ARGUMENTS during inlining.
If you want to be more specific on what is to be moved, we could either
add some VAR_DECL flag bit (but that is expensive, we don't have many),
or perhaps just check that DECL_CONTEXT (DECL_ORIGIN (v)) == DECL_ORIGIN (fn)
(but is that ever false?).
> mentioning DWARF in tree-inline looks odd,
> unless we get rid of the other formats - something I'd of course
> welcome ;))
That can be fixed, I can replace the DWARF terminology with something more
fuzzy.
Jakub
