Re: [CFG] Loop represenation & new loop optimizer works

[Jan Hubicka <jh at suse dot cz>]

> Hello.
> 
> > > > Why exactly this is needed? The basic block structure is zeroed before
> > > > used, so they should be 0 by default.
> > > 
> > > Then something doesn't work, as it happened to me that these fields had
> > > non-NULL values just after find_basic_blocks and it made problems in
> > > cfgcleanup.
> > 
> > Hmm, in case the life info has been already built, the values are allocated.
> > The is the case after GCSE, but it should not be problem, as the code will
> > just maitain dead copies around.  Where exactly did it crashed?
> 
> Problem is, that there happened to be both blocks with and without life
> info. When these blocks get merged, the result will only have
> global_live_at_start non-NULL, but cfg_layout_duplicate_bb expects that
> if global_live_at_start is non-NULL then global_live_at_end is, and
> segfaults trying to copy it.

Hmm, I guess the proper sollution is to explicitly free the bitmaps once
liveness information is no longer maitained consistent.
Then all pointers will remain NULL and it should work happily.

> > 
> > Please.  We do the pass trought all BBS anyway in the commit_edge_insertions.
> 
> Right. Would not be better to maintain a chain of new bbs? As you noted, in
> this situation it would not help, but perhaps it would be useful on other places.

It is somewhat more expensive and it is bit tricky to keep chain consistent
after removing blocks.
I guess once we remove the linear ordering of BB indexes, it will be easy to
identify new blocks just from their UIDs, so special code will not be needed.

In case you are really interested, just implement remove the ordering,
as next merging is not that far now.  I would like to see that done till
mid february. Bit as it is even more involved, perhaps we can just use
the BB_NEW flag, get the loop code in and then continue on more issues.

Honza