Re: df.c and partial writes/REG_EQUAL notes

[Daniel Berlin <dan@cgsoftware.com>]

Jan Hubicka <jh@suse.cz> writes:

>> Richard Henderson <rth@redhat.com> writes:
>> 
>> > On Tue, Sep 25, 2001 at 11:32:40AM -0400, Daniel Berlin wrote:
>> > > Your web code must be pretty slow on large test cases, since my ebitmap 
>> >> patch *still* hasn't been reviewed.
>> >
>> > Um, no, it *has* been reviewed.  I told you how I wanted
>> > it changed.
>> >
>> Ah, yes.
>> You want no more than 2 bitmap implementations in the compiler,
>> and want it replaced all at once, which is another questionable idea.
> It IMO makes sense.
> As the current bitmap can have advantage possibly only in extremly large and
> sparse bitmaps we don't have currently (and that should be better handled by
> tripple indirection or more fiting underlying datastructure than linked lists
> are) and most of users to my best knowledge will benefit from the
> implementation, it is wortwhile to do it.  All our bitmpas I am aware of are
> maximally quadratic (regsXinstructions) or so, that should be always small
> enought for ebitmap implementation.
>
> Or do I miss something important?
That making a change that affects basically every single part of the
compiler, wholesale, is generally a bad idea to do in one single step,
since it makes it harder to track down where the real problem is.
In this case, having *done* it, I can say this was definitely true.

>
> In case you don't have motivation to do the step, I may try next week, as
> working (and fast) dataflow is good and bitmap.c is one of top CPU hogs of
> current compiler and we really need to get dataflow module working
> and used.

Don't bother, i already did it.
You'll note that reload makes too many bitmaps, and the 16-24 bytes
more overhead + the empty array pointers that the ebitmap takes causes
100-150 meg more memory.
Just another point that we shouldn't up and replace them wholesale,
rather do it incrementally.

I have resolved this problem by reworking the internals to
not need to store empty words at all (ie not even pointers to them).

I also replaced bitmaps with them already.  The new internal storage
mechanism requires changes to sbitmaps so you can properly
and/or/copy/etc bitmaps of differing bit sizes.
I.E. it'll do the right thing, as long as the destination is big
enough to hold the right result. sbitmap_a_or_b (350 bit sbitmap, 25
bit sbitmap, 200 bit sbitmap) will work properly.
It would and/or/etc random memory before.

However, experience in doing this just helps prove my point. I tried
doing it all at once, and it made finding the real cause of the bugs
impossible.

> > 
>> This was your "review".
> Please lets work together to get gcc better, not fight.
Who is fighting?
I put review in quotes because i do not believe he reviewed the patch
itself, as i stated in my message to Gerald.

I should also note that there was a bug in ebitmap.h in
EXECUTE_IF_SET_IN_EBITMAP that a meaningful review of the patch would
have caught. 

>
> Honza
> > 
>> >
>> > r~
>> 
>> -- 
>> "When I was five years old I was on a merry go round.  There was
>> a gunshot nearby.  The horses stampeded.  There I was running
>> down the street on a purple wooden horse.
>> "-Steven Wright

-- 
"Last time I went skiing, I had to get up at 5:00 in the morning.
I knew I couldn't do that, so I slept with my skis on.  My ride
came at 5:30 in the morning, couldn't wake me up so he carried
me out of the house, put my skis on the roof rack of the car,
and drove to the mountain.  Seventeen miles later, I woke up out
of this incredibly bizarre dream that I was skydiving
horizontally.  I'm sure this has happened to you.
"-Steven Wright