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


> 
> > 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.

OK, we also inilne static functions called once as -O2, but I guess these does
not happen for shared headers either, so I would say that ignoring this
is fine in the case it won't do something really bad (like producing
undefined symbols when accessing the abstract die from other unit or so)
> >
> > 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.

I seem to recall that he was about to fix it and found that it has been
already done... don't reacall details tought, but definitly I seen
version of GDB that support -feliminate-dwarf2-dups
> 
> > 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.

OK.  I remember Zdenek did that, and if I recall -feliminate-dwarf2-dups
was win for libstdc++ but not for instance for GCC binary itself, so it
depends on coding style.  I will re-try.
> 
> > 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.

I don't think -feliminate_dwarf2_dups is making this too much
complicated, so we still can keep it.

The problem is that outline_function is called too often. Function can
be DECL_INLINE and !DECL_DECLARED_INLINE at -O3, but still
!cgraph_possibly_inlined_p as with -funit-at-a-time we work out that the
function has never been inlined, so we end up aborting when doing
abstract DIE for function not declared inline and not inline.

changing the interface to outline_function so the dwarf2out.c (and other
debug formats) decide on whether they need to output abstract DIE at all
or not is relatively easy.
But the function probably need new name, something like notice_function.

Does this seem to make sense?
> 
> > 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.

I found that... Funny how many side cases we have.  It would be all much
easier with new cgraph code, but we still need to support non-tree
frontends :(

Honza
> 
> Jason


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