[Bug rtl-optimization/58960] [4.9 regression] ICE in bmp_iter_set_init

["abel at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58960

Andrey Belevantsev <abel at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vmakarov at gcc dot gnu.org

--- Comment #6 from Andrey Belevantsev <abel at gcc dot gnu.org> ---
Well, I guess one is responsible for what one has tamed, so reproduced now.

The issue is actually simple -- we add new blocks when scheduling (they are
recovery blocks for speculation insns) and for them we do not calculate
DF_LIVE_IN bitmaps so we segfault when we try to read those bitmaps in the
sched pressure info initialization code.  I see the following possible fixes:

1) calculate liveness for the new blocks via the DF interface.  Now it doesn't
look like anyone is using the partial analysis interface via df_set_blocks
nowadays, and the new blocks do not form a loop so df_analyze_loop Richard has
added would not work.  What can be done is gather the new blocks in a separate
bitmap and add their preds/succs which should hopefully have the right liveness
info, so partial df_analyze on those can do the trick.

2) manually calculate liveness for the new blocks.  Again DF doesn't offer much
for this, you'd need to df_grow_block_info for df_live and then try deriving
the liveness information from the original block's successor.  This will need
some manual propagation through the new block as we do in the selective
scheduler.

3) decide that the recovery code is supposed to be cold enough so we don't care
about applying register pressure sensitive code to it, thus reset
sched_pressure to SCHED_PRESSURE_NONE for all newly created regions.  The patch
from the previous comment does just that; we only need to free the
sched-pressure data immediately at this point as we later fail to do that and
ICE in IRA later.  I had to factorize the finalization code in a separate
function for that.  
The patch supports only blocks ending up in the new region, not the same
region, but it looks like the current code always puts recovery blocks in the
new region.

Vlad, what's your opinion on this?