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: [C++] Avoid one place of frontend calling into targetm


> Jan Hubicka wrote:
> 
> >> but, at least, the initializer only is called once.  Because this change
> >> in behavior does not return to the original assembly before the first
> >> patch, I tend to doubt that this patch fixes the regression correctly.
> >> But closer!
> > 
> > Well, actually this was intended (in fact the code was produced before
> > my patch too, just because of bug/misunderstanding in cgraph code it was
> > always optimized out as unreachable and accidentally made everything
> > working).  With -O1 the constructor will be already inlined.
> 
> FWIW, I think Jan's patch makes sense.  The only part I'm not sure about is:
> 
> !   /* It can be a static function as long as collect2 does not have
> !      to scan the object file to find its ctor/dtor routine.  */
> !   TREE_PUBLIC (current_function_decl) = ! targetm.have_ctors_dtors;
> 
> Jan, is there something in cgraph that will make sure the function is
> public on targets that use collect2, now that you're unconditionally
> making the function private in the C++ front end?  I can't read AIX
> assembly well enough to be sure.

This is what I think was source of the duplication - ie cgraph is now
collecting all funcions with DECL_STATIIC_CONSTRUCTOR/dtor set (as
c-common code did originally too) and will produce a wrapper function
that is one per file.
> 
> So, from my perspective, I think the patch is OK.  If it fixes the AIX
> test failures, I think we should check it in, if that's OK with David.
> 
> However, Jan, it would be nice if you could arrange for these functions
> to be always-inlined, even at -O0.  There's no reason for them to be
> separate; the user doesn't know anything about them anyhow.  I don't
> think that's a big deal, but it would be a bit tidier.

OK, it is not dificult to get this done incrementally (basically at the
time I am collecting the list, I need to drop alwaysinline attribute)
C++ frontend can most probably do the same for
static_construction_destruction and friends.  I guess there are no
functions that are both static constructors and can be called dirrectly
from other places?

Honza
> 
> Thanks,
> 
> -- 
> Mark Mitchell
> CodeSourcery
> mark@codesourcery.com
> (650) 331-3385 x713


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