repost: [DF] Use HARD_REG_SETs instead of bitmaps

[Dimitrios Apostolou]

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