This is the mail archive of the 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]

Patch for reusing virtual operands.

When Diego first statred doing MEMSSA, we needed to change virtual
operands, and I cobbled together the changes to allow multiple VUSES
both in vuses and on the rhs of a vdef. 

I didn't want to implement a new reuse mechanism until MEMSSA worked in
some final form so I could measure the results and usage
characteristics.  Now that its checked into mainline, I guess we've
reached that point :-)

So, this patch implements memory reuse for virtual operands.  I've run
and comared a number of things, and generally, I see a 15%-60% reduction
in the memory allocated by the operand scanner. This translates into a
1-2% overall reduction. Hopefully that is reflected when the memory
tester runs on this code :-)

Execution time is fairly stagnant, it the usual story, a few things
appear to get slightly faster, a few thing appear to get slightly
slower.  In particular, I get inconsistent results with the large
pathological cases.  Presumably that is because of cache issues.
Overall it seems to be a wash.

A couple of tidbits for operand memory:
 		original memory		new memory
cpgram.ii	19179 kB ( 4%) ggc	11113 kB ( 2%) ggc
verify.ii	2361 kB ( 4%) ggc	1464 kB ( 2%) ggc
insn-attrtab.i	4544 kB ( 6%) ggc	2780 kB ( 4%) ggc
tramp3d-v4	116188 kB ( 9%) ggc	96929 kB ( 8%) ggc

Along the way, I cleaned up the code a bit as well.  Both vdefs and
vuses now share the same data structure instead of being separate.  This
allowed for some more commoning of routines in tree-outof-ssa.c.  The
finalize_defs routine was also doing some silly work which I removed.  I
may do a few more cleanups later, but this is a good start.

Memory chunks are now allocated in a graduating step up to the 511
operands Diego had set it to last week.  A lot of small functions didn't
need that much space, so now we allocate the first block as 30, then the
second at 110 and finally all remaining chunks are 511.  This seemed to
produce the most reasonable results from my testing. It'll do for now

This has been bootstrapped on i686-pc-linux-gnu with no new regressions.
Patch attached, just checked it in.


Attachment: PPP
Description: Text document

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