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 10:23:24 +0200, Jan Hubicka <hubicka@ucw.cz> wrote:
> 
> >> On Sun, 19 Oct 2003 10:00:39 +0200, Jan Hubicka <hubicka@ucw.cz> wrote:
> 
> >> > Also what about COMDAT functions?  I guess the debug info should be
> >> > conservative then and always claim that function has been inlined as it
> >> > may be inlined in the other compilation unit, right?
> >> 
> >> I don't see what COMDAT has to do with this.  If the function is inlined in
> >> another translation unit, it will have debug info there.
> >
> > So the debug info above is generated for each inline copy of the given
> > function separately?  How we can end up with DW_INL_declared_not_inlined
> > then?
> 
> 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
-felliminate-dwarf2-dups we should separate all DECL_INLINE functions?

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?
> 
> > In the case it is generated just once, I would expect commonized
> > functions after linking to also commonize the debug info so it should be
> > conservative?
> 
> 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?

Honza
> 
> Jason


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