Re: [PATCH] Fix up DW_TAG_formal_parameter placement

[Richard Guenther <rguenther at suse dot de>]

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.