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


> On Mon, 2003-12-01 at 16:10, Jan Hubicka wrote:
> > > In message <20031201200143.GC20851@kam.mff.cuni.cz>, Jan Hubicka writes:
> > >  >> > From: law@redhat.com
> 
> > >  >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.
> > 
> Is it specific optimizations that are suspect to it? ie, can you tell
> which optimizations are responsible for taking the performance hit when
> we dont reuse SSA_NAMES?
> 
> Presuming that is isn't SSA->normal, which I would expect to be flat
> with and without SSA_NAME resuse, the same routines could be used if its
> one place.  SSA->normal compresses the SSA_NAME list into a partition
> list which is dense, and then allocated memory and manipulates the dense
> list.  
> 
> If there is a specific optimization that is impacted by sparser
> SSA_NAMEs (ie, allocating large vectors over SSA_NAMES indexes), the
> partitioning data structure could be used to compress it to just
> elements that matter. If it makes sense. If the problem is spread across
> a lot of the optimizations then something else might be better.

I didn't investigated this in detail.  However it don't have to be so
bad in general case (the Gerald's testcase is kind of peak right now,
almost any change makes it to regress, so that is why I am using it to
ensure that I didn't made memory situations worse).

It seems to me that there are several places we allocate bitmaps and
varrays relative to maximal SSA_NAME uid..
> 
> I dont particularly like re-using SSA_NAMEs versions. Expecially in
> large programs Im debugging, I tend to grep for VAR_v in a.c.* listing
> files to see where uses appear and dissappear. I guess its not a huge
> thing to filter out, but I can see it being very confusing sometimes,
> especially if the new use is at all similar to what the old use was.
> 
> RTL never recycles register numbers does it? I dont recall ever doing it
> on any other compiler I used either. Thats not to say there isn't some
> benefits from it :-)
Yeah, we don't recycle register numbers, owever we do recycle insn uids
and basic block ids.
I agree that recycling these makes it harder to debug in some cases...

OK, what about delaying this thread until we can actually free the
arrays allocated by GGC so we see how the situation behaves in practice?
It seems to me that any benchmarks done right now are not very acurate
and without benchmarks it does not make sense to try to discover complex
sollutions :)

Honza
> 
> Andrew
> 


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