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.
