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 Dimitris P.S. we badly need a gxr site :-)
