This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Avoid some unnecessary set_cfun calls
- From: Richard Biener <rguenther at suse dot de>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Richard Sandiford <rdsandiford at googlemail dot com>, Michael Meissner <meissner at linux dot vnet dot ibm dot com>, gcc-patches at gcc dot gnu dot org
- Date: Wed, 13 Nov 2013 11:53:32 +0100 (CET)
- Subject: Re: [PATCH] Avoid some unnecessary set_cfun calls
- Authentication-results: sourceware.org; auth=none
- References: <20131113094909 dot GI27813 at tucnak dot zalov dot cz> <alpine dot LNX dot 2 dot 00 dot 1311131123000 dot 4261 at zhemvz dot fhfr dot qr> <20131113104848 dot GJ27813 at tucnak dot zalov dot cz>
On Wed, 13 Nov 2013, Jakub Jelinek wrote:
> On Wed, Nov 13, 2013 at 11:27:10AM +0100, Richard Biener wrote:
> > > Also, I wonder if we couldn't defer the expensive ira_init, if the info
> > > computed by it is used only during RTL optimization passes (haven't verified
> > > it yet), then supposedly we could just remember using some target hook
> > > what the last state was when we did ira_init last time, and call ira_init
> > > again at the start of expansion or so if it is different from the last time.
> > > For i?86/x86_64/ppc* this would be whether the current function's
> > > DECL_FUNCTION_SPECIFIC_TARGET is the same as one for which ira_init has been
> > > called, for rx whether interrupt attribute is the same and for mips whatever
> > > is needed.
> >
> > I wonder why we cannot move all the stuff we re-init to a member
> > of struct function (or rather have a pointer to that info there
> > to cache it across functions with the same options). That is,
> > get rid of more global state? That would make switching back
> > and forth cheaper.
>
> Isn't that what the SWITCHABLE_TARGET stuff is all about?
Maybe - I didn't follow all the changes in this area.
> So, perhaps we should just define SWITCHABLE_TARGET on i?86/x86_64/powerpc*
> (and rx if maintainer cares) and tweak it to attach somehow
> struct target_globals * to TARGET_OPTION_NODE somehow.
> A problem might be that lots of the save_target_globals
> allocated structures are heap allocated rather than GC, so we might leak
> memory. Wonder if save_target_globals couldn't just compute the
> aggregate size of all the structures it allocates with XCNEW right now
> (plus required alignment if needed) and just allocate them together
> with the ggc_alloc_target_globals after the target_globals structure
> itself.
If you want to re-use it from functions with same options don't you
have a hashtable anyway? You could add a reference count.
Richard.