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: [tree-ssa] Avoid nondeterminism in tree-ssanames


> In message <20031201200143.GC20851@kam.mff.cuni.cz>, Jan Hubicka writes:
>  >> > From: law@redhat.com
>  >> > Date: Mon, 01 Dec 2003 10:28:13 -0700
>  >> 
>  >> > 1. Re-using SSA_NAMES across different functions is a bad idea.  Please l
>  >et's
>  >> >    not do that.  The whole point of the SSA_NAME cache is to avoid silly 
>  >> >    GC allocations within the SSA path for a single function.
>  >> 
>  >> So, maybe the best thing to do is to reintroduce a freelist, but do it
>  >> right?
>  >> 
>  >> A 'deletable' freelist is supposed to look like:
>  >> 
>  >> if (freelist_head)
>  >> {
>  >>   <type> tmp;
>  >>   tmp = freelist_head;
>  >>   freelist_head = tmp->next;
>  >>   memset (tmp, 0, sizeof (*tmp));
>  >>   return tmp;
>  >> }
>  >> else
>  >>   return ggc_alloc_cleared (sizeof (<type>));
>  >> 
>  >> That is, the new object should be treated as uninitialised data.
>  >
>  >I did that, but it did increase memory usages.
>  >The idea of re-using freed SSA_NAMES seems to be important factor.
>  >So I think that even with ggc_free, we will want some scheme to re-use
>  >SSA_NAMEs in this particular case.  (or compact them in between passes
>  >that would however make dumps dificult to read)
> Reusing the SSA version #s is the least interesting part of SSA_NAME
> management and there are certainly other ways to implement it.  The
> only reason it was included at all was because it was trivial to
> implement within the manager.
It makes 11% performance difference on Gerald's testcase on my setup,
just FYI.

Honza
> 
> jeff
> 


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