Re: repost: [DF] Use HARD_REG_SETs instead of bitmaps

[Dimitrios Apostolou <jimis at gmx dot net>]

On Mon, 7 Nov 2011, Jakub Jelinek wrote:
> On Mon, Nov 07, 2011 at 12:01:29AM +0200, Dimitrios Apostolou wrote:
> > On Sun, 6 Nov 2011, Joern Rennecke wrote:
> > > But where HARD_REG_SETS make no material difference in speed, and the
> > > compilation unit has no other tight coupling with tm.h, it would really
> > > be cleaner to move from HARD_REG_SETS to a target-independent type,
> > > like sbitmap or bitmap.  Maybe we want something more lightweight than
> > > an sbitmap, like passing in a HARD_REG_ELT_TYPE *base, int n_elements
> > > pair to describe the data - n_elements would be set to HARD_REG_SET_LONGS.
> > > When you are doing anything time-critical with hard register sets,
> > > there is little point having the same size stored in multiple places,
> > > you might as well keep it in a register and pass it around.
> > > Basic operations could presumably be inlined, so the main overhead would
> > > be loop overhead.  With the right loop unrolling applied, these loops
> > > should be well predictable.
> >
> > Working with bitmaps in gcc made me really miss the simple bitmap.h
> > of the linux kernel. I'm not sure if we can borrow from there. More
> > info at:
> >
> > http://lxr.linux.no/#linux+v3.1/include/linux/bitmap.h
>
> Hm, what else is hard-reg-set.h?

It's about the same performance-wise, but:

* much uglier because of all the #ifdef cruft
* less useful since it can't be used as a generic bitmap
** Closest generic bitmap is sbitmap.h, but IMHO it's more complex than it 
should be.

I'd love to have the kernel bitmap.h in libiberty.


> When you are dealing with pseudos etc.
> sparse bitmaps are very often better.

Indeed. They are much better memory-wise, but they have a non-negligible 
overhead performance-wise. I've noted somewhere to replace all hot bitmaps 
with ebitmaps and see what happens, whenever I have the time...


Dimitris