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: [patch] Rewrite building of virtual operands


On Tue, 2006-03-07 at 14:23 +0100, Zdenek Dvorak wrote:
> Hello,

> Up to these tests I could not imagine using sbitmaps for this might be a
> good idea, but I will probably give it a try, just to see the numbers
> (although even if they are good on typical code, which they probably
> would be, there most likely exist pathological examples that would
> prevent their usage).
> 
true of just about everything :-)  The bad side of sbitmaps is likely to
be the allocating/deallocating, but perhaps they are implemented such
that it isnt an issue. The operand mechanism tries to be sensitive to
memory allocations.

> > timings of your patch. I never wrote one with bitmaps of any sort.
> > notice those are timing of *just* the operand cache, not overall time,
> > and on my 3Ghz P4.
> 
> How do you measure them? TV_TREE_OPS seems to basically measure noise,
> given the precision it uses.

well, its not just noise on the machine I used, and the slower the
machine/less memory, the more obvious it becomes. its like 3 seconds of
operand time on my machine and and extra .5 or .6 seconds with the
patch, repeatably.
> 
> > The opfinalize.h routines are for the sake of
> > speed, and other than a bit of ugly appearance (where are C templates
> > when you need them anyway :-), they are pretty clean.  They rarely need
> > to be touched.  I also don't find them that difficult to work with, but
> > feel free to expand them inline if you do.  
> 
> here is the patch that expands the functions.  To make it simpler to
> review, it makes no functional changes (i.e., all cleanups enabled by
> the specialization will be in followup patches).

The patch seems fine, go ahead.

I also wouldn't bother with too many more changes beyond checking the
maydef list when processing mustdefs. I just finished hacking up the
operands for dnovillos' memory ssa changes, and all the virtual operand
stuff is going to be gutted anyway. virtual operands will be a vector of
virtual uses, and there will be an optional def which will be used by
maydefs and mustdefs.   I can make them share the same structure at that
point.  There will be at most one may/must and one vuse per stmt.

With the simplifications this will make, some sort of a bitmap might be
the logical choice in the parsing section, but we'll have to see exactly
what dnovillo ends up needing, its too early to tell.

Andrew


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