Re: PROPOSAL: inlines: nesting, looser correspondence, and size reduction

[Jason Merrill <jason at redhat dot com>]

>>>>> "Todd" == Todd Allen <todd.allen@ccur.com> writes:

> I propose that the definition of an abstract instance tree be changed
> slightly to exclude any abstract instance trees nested within it.  Likewise,
> the definition of a concrete instance tree should be changed to exclude any
> concrete instance trees nested within it.  I suspect this was the intent from
> the start, so you may just want to think of this as a clarification.

I agree.

> Issue #2:

> The set of attributes listed in 3.3.8.1 to be excluded from an abstract
> instance tree, and the same set in parentheses in 3.3.8.2 are too C-centric.
> They don't take into account additional concrete-instance-dependent
> attributes that might be added by new languages and/or vendors.  I propose
> making the text more vague and changing the sets into suggested lists for
> C-like languages.  Arguably, this is just a clarification, too.

More vague like "attributes which refer to code locations, such as <current
list>"?

> Issue #3:

> So, I propose eliminating the exceptions as stated, and replacing them with
> the permission (but not even the requirement) to omit any debugging
> information entry from a concrete instance tree if it would contain no
> attributes (other than DW_AT_abstract_origin) and no children.  That should
> be sufficiently vague as to be useful for any language, and should cover the
> explicit exceptions from the DWARF 2.0.0 document, at least for C-like
> languages.  We could retain the explicit exceptions listed there as
> suggestions for things to be omitted in C-like languages.

Sounds good to me.  In general, I agree with the approach of giving a rules
in terms of conditions, rather than lists of values.

> Issue #3b:

> Furthermore, I would like to loosen the restriction on one-to-one
> correspondence between concrete and abstract instance trees to allow a
> concrete instance tree to omit a debugging information entry if that
> debugging information entry becomes useless in the concrete instance.  

I think this is already the case:

       Note, however, that  the  reverse  is  not  true.   A  given
       abstract  instance  tree  that  is  associated  with a given
       concrete inlined instance tree may (and quite probably will)
       contain  more  entries  than the associated concrete inlined
       instance tree (see below).

> Issue #4:

> It is useful for a concrete instance tree to create new debugging information
> entries that were not contained in the abstract instance tree.  This is true
> in cases where there is no way to know, when generating the abstract instance
> tree, that a given entity will be needed, say, as part of the description of
> another entity that was in both the abstract and concrete instance trees.

Seems reasonable.

> Issue #5:

> I think the DWARF 2.0.0 document is unclear on how to describe inline
> subroutines that contain nested subroutines.  To clarify, I am not talking
> about concrete instances nested within other concrete instances, but rather
> about inline subroutines that contain other subroutines, such that from the
> nested subroutines ones could up-level reference variables from the outer
> inline subroutine.

> In the case where the nested subroutine isn't inline, then arguably it's
> straightforward how to describe them.  Still, I propose to add text to
> clarify the issue and also to act as contrast the following text.

> In the case where the nested subroutine is inline, it isn't clear whether or
> not the abstract instance tree for the nested subroutine should be reiterated
> in the concrete instance tree for the outer subroutine.  We believe it will
> include no new useful information, so applying the conclusion from Issue #3,
> we think there is no point in reiterating it there.

I agree; this seems analogous to types.

> Likewise, it isn't clear whether or not the abstract instance tree must
> contain abstract concrete instance trees for any inline expansions that
> occur for nested subroutines.  We think there is no useful information
> that would be emitted there, either, so think they should be omitted.
> (In such a case, all the useful information would be in the concrete
> instance tree for the nested subroutine within the concrete instance tree
> for the outer subroutine.)  This is an application of the proposal for
> Issue #1.

Makes sense.

Jason