df.c and partial writes/REG_EQUAL notes

[Daniel Berlin]

Jan Hubicka <jh@suse.cz> writes:

>> 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.
I did this as well (including a define to outline them, for profiling
purposes/debugability).  There are a few cases where it's not inlined,
but the compiler seems to make the right choice here.

> 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).

It's actually the insn chains reload uses + life analysis.
Reload *seems* creates 2 bitmaps per insn, at least. I'm just going by
the insn chain structure here.

>
>>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.
Correct.
However, it's at the expense of more memory traffic.
They do work, and do bootstrap/make check, i'm just tuning the block
size and whatnot.


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

BTW, if the logical operations start to appear at the top of the
profile, we could just vectorize it for various platforms.
This is one reason i use auxiliary static inline functions for the
actual blocks.


>
> Honza

-- 
"I was trying to daydream, but my mind kept wandering.
"-Steven Wright