On Thu, 4 Oct 2012, Jakub Jelinek wrote: > 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.
Ok, I think I know better what I was after now thinking about this more. initialize_inlined_parameters (id, stmt, fn, bb); if (DECL_INITIAL (fn)) - prepend_lexical_block (id->block, remap_blocks (DECL_INITIAL (fn), id)); the context shows it, initialize_inlined_parameters would be the natural place to "inline" optimized out parameters represented as VAR_DECLs with PARM_DECL DECL_ORIGIN. Of course the way remap_blocks works makes this difficult, if not impossible (or more ugly than your solution). So in the end your patch is ok as-is. Thanks, Richard.
