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 17:00, Jan Hubicka wrote:
> > On Mon, 2003-12-01 at 16:10, Jan Hubicka wrote:
> > > > In message <20031201200143.GC20851@kam.mff.cuni.cz>, Jan Hubicka writes:

> > 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..

Yeah, but I dont think you'll see much measurable difference in those
cases. Typically I suspect the kind of place you'll really see a
difference is when you have a multi-dimensional array indexed by
SSA_NAME version number. This is the case with the conflict graph in
SSA->normal.

s
> 
> 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 :)
> 
Yes, much of these things are in fact moot if we get the GC fixed to do
what we need.

Andrew

So what are we doing to the GC?  Are we fixing the zone collector so we
can allocate pages to specific purposes?  And will there or will there
not be a free list mainatined within the zone?

I've abstracted out the use and def operands, Im going to make it work
for vuse and vdef operands as well. These seem like very likely
candidates for a zone as well, if it includes a free list, and can
handle small allocations easily. I've got a quick and dirty one that I
was going to provide with the abstraction which is very specific, but
efficient.  If GC will provide what I need, I wont worry about it.



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