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? When you are dealing with pseudos etc.
sparse bitmaps are very often better.
Jakub
