This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Avoid some unnecessary set_cfun calls
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Richard Biener <rguenther at suse dot de>, Michael Meissner <meissner at linux dot vnet dot ibm dot com>, gcc-patches at gcc dot gnu dot org
- Date: Sat, 16 Nov 2013 11:25:06 +0000
- 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>
Jakub Jelinek <firstname.lastname@example.org> writes:
> 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?
> 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
Yeah, that might be worth doing. I think the only non-GCed structures
with subpointers are target_ira_int and target_lra_int, but we could
probably convert them to GCed structures. (And perhaps use the same
technique recursively. E.g. LRA could work out the maximum number of
operand_alternative structures needed and allocate them in one go.)