This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] PR 12389


On Sun, 19 Oct 2003 19:45:41 +0200, Jan Hubicka <hubicka@ucw.cz> wrote:

>> If a function is declared inline but not actually inlined, we may still
>> separate it into abstract and inline instances, in which case we would use
>> DW_INL_declared_not_inlined.  This is useful for -feliminate-dwarf2-dups,
>> which relies on the debug info for a particular header being identical in
>> different translation units.
>
> With my patch, I produce abstract instance only when inlining actually
> happens in given compilation unit.  So you suggest that with
> -feliminate-dwarf2-dups we should separate all DECL_INLINE functions?

I think that might be useful.  But I don't know without doing some actual
measurement.

> How this is different with -O3?  Then we can inline even functions not
> declared inline (this actually happens even for functions called once at
> -O2) so perhaps we need abstract instances for all functions just for
> sure as we don't know what happens in the other unit?

No, that seems like overkill.  Debugging at -O3 is already pretty dodgy.

>> When we use section groups, we can discard the debug info for a function
>> along with the function itself.  But in the case of an inline function,
>> this only applies to the concrete instance; we will still have a separate
>> abstract instance.

> OK, and contrete instance does not contain DW_AT_INLINE, so it is not
> dependent on particular inlining decisions, right?

Right.

[different mail]
>> As discussed in my last mail, we probably also want to do this if
>> DECL_DECLARED_INLINE_P (decl) && flag_eliminate_dwarf2_dups.  But we should
>> do some measurement with -feliminate-dwarf2-dups (if it still works) to
>> make sure it's an improvement.
>
> We use -feliminate-dwarf2-dups on hammer-branch compiler and it works at
> least there.

Hmm, perhaps someone fixed GDB while I wasn't looking.  It doesn't seem to
have been Zdenek, though; he doesn't appear in the GDB ChangeLog.

> What kind of measurement of -feliminate-dwarf2-dups you do have in mind?

I'd probably just build libstdc++.so with and without the change and see
which version is smaller.

[different mail]
>> Just to be sure, when not using -feliminate-dwarf2-dups, we should not
>> produce DW_INL_declared_not_inlined either, right?

I suppose not.

> OK, adding the abort shown another problem.  There is another
> DECL_INLINE test inside toplev.c.  It seems to me that that test is
> deciding on whether abstract DIE will be output or not, so it should
> check the other condition in second hunk of dwarf2out that actually check
> flag_eliminate_dwarf2_dups and thus is dwarf2 specific, so perhaps we
> need change in interface and call that function each time and make debug
> output driver to decide whether or not it will do some work?

Hmm, if the f_e_d_d case is going to complicate the code, it probably isn't
worth handling.

> For inline functions we never output out-of-line copy for we never
> actually output the abstract DIE?

We output the abstract DIE so that the inlined copies can refer to it.

Jason


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]