Re: df.c and partial writes/REG_EQUAL notes

[Jan Hubicka <jh at suse dot cz>]

> As to my opinion of the underlying issue, I'll say first that I have not
> looked at the patch.  However, I agree with RTH that we don't need *three*
> bitmap implementations.  That being said, however, I could be convinced that
This is my intuition too.
I've looked at the code and after some thinking, Daniel's approach seems
to make more sense. To sumarize my conclusion:

The problem Daniel run into, and that sounds understandable is that we have
different needs for the bitmap reprezentation:

1) we need lightweight fast small bitmaps (as hard-reg-sets) where sbitmap is
   very good choice. For instance it can be nice to use them even in combine
   for the "nonzero" bits and similar cases where we artificaly limit our
   implementation for HOST_WIDE_INT.  This would be a must to get good
   optimizations on packed types in future probably.
2) we need fast and unavoidingly large, sparse bitmaps (such as those used
   by dataflow or LCM).  The ebitmap framework sounds sane here.
   It can be nice to make fast path of bit set/test functions macro, as
   our profiles keeps these functions at the top in the ammount of function
   calls.
3) we need sparse and space efecient bitmaps in some cases.
   (Daniel claims he run into space problems with ebitmap in reload, probably
    because of relativly small and numberous bitmaps used by life analyzis
    for reg_sets).

>From this point of view the 3 implementations appears to make sense.
Daniel, in other email described his attempt to make ebitmaps space efecient,
if that will work, we will end up with 2 bitmap reprezentations and this
appears to make sense, given the fact above.

So lets turn into techincal issues now and try to figure out whether we can
bring data reprezentation that fits 2) and 3).

Honza