Re: [patch] Rewrite building of virtual operands

[Daniel Berlin <dberlin at dberlin dot org>]

On Tue, 2006-02-28 at 19:20 +0100, Michael Matz wrote:
> Hi,
> 
> On Tue, 28 Feb 2006, Andrew MacLeod wrote:
> 
> > Its done that way for a reason. I spent a *lot* of time tuning this
> > code. This lies underneath almost everything ssa does, so minor changes
> > can impact the speed of all ssa passes, especially in the more
> > pathological cases. By using an sbitmap, you are going to have a lot of
> 
> He's using bitmaps, not sbitmaps.  _much_ more cache friendly and faster
> to iterate on, and as additional goodies you get sorting by index and
> merging of duplicate entries for free, better than any VEC could ever be, 
> for sets where you need these properties ...

This is only true if the operands in the list are very very dense (small
files they are, large files they unfortunately sometimes are not, it
depends on a lot of factors, like inlining, etc.  For a large C++
testcase like tramp3d, i'd imagine you'd get a good answer to density
and speed)

> 
> > additional allocates and frees for the sbitmap's... the in_list bits of
> > the annotations are already allocated and available. I agree they are a
> > touch awkward, but they are faster.  Did you try to time this patch? its
> 
> ... though a timing comparison would be interesting.

Not just interesting, i'd think it would be required to show that this
patch is a good idea, since it's changing a portion of code so critical
to compile speed.

> 
> 
> Ciao,
> Michael.
>