Re: [PATCH] Do not set BB_SUPERBLOCK in loop-unroll.c:split_edge_and_insert

[Jan Hubicka <hubicka at ucw dot cz>]

Steven,
> 
> Even with the BB_SUPERBLOCK flag out of the way, I now run into new
> problems, because of Ian's lower-subreg pass. Instead of fixing the
> CFG in place when necessary, Ian makes the pass use
> find_many_sub_basic_blocks to fix up some rare cases where additional
> control flow edges may be required after lowering subregs.
> 
> And, you've guessed it, find_many_sub_basic_blocks doesn't work in
> cfglayout mode.
> 
> So now I can stay in cfglayout mode over even fewer passes, until I
> (or, I'd really hope, Ian) will have taught lower-subreg to update the
> CFG in place. Ian has already told me why he needed this, and I hope
> we can find some time to solve the issue in a cleaner way.
> 
> Can we please put a "ban" on new uses of find_many_sub_basic_blocks?

Originally sub_basic_block splitting was invented for one simple reason
- the RTL expanders are organized in a way that they can introduce new
CFG any time so after all late insertions of RTL you theoretically
need to split basic blocks.

There is no information given to the passes what kind of control flow is
constructed by splitting/expanding, so it still seems to me that
find_many_sub_basic_blocks is needed unless we wnat to reorganize all
machine dependent expansion to in place adjust CFG.

Of course the splitting should not hit the problem you describe - ie the
fallhru edge should be either eliminated if no longer needed for
whatever reason or just stay in place.  I am bit busy till Monday, but I
can look into this at Tuesday, if you ping me ;).  There are bad and
good uses of this infrastructure, IMO.

Honza

> 
> Gr.
> Steven