This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] Rewrite building of virtual operands
- From: Andrew MacLeod <amacleod at redhat dot com>
- To: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
- Cc: gcc-patches at gcc dot gnu dot org, dnovillo at redhat dot com
- Date: Tue, 07 Mar 2006 10:17:25 -0500
- Subject: Re: [patch] Rewrite building of virtual operands
- References: <20060227170004.GA9176@atrey.karlin.mff.cuni.cz> <1141149999.10812.362.camel@localhost.localdomain> <20060228230829.GA22514@atrey.karlin.mff.cuni.cz> <1141222597.10812.426.camel@localhost.localdomain> <20060307132309.GA16620@atrey.karlin.mff.cuni.cz>
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