If I do that I run into an infinite loop in fixup_reorder_chain()
in its first for loop at:
while (NEXT_INSN (insn)) <<<<<< HERE
insn = NEXT_INSN (insn);
It looks like there is an undocumented assumption about insn-chains and the rbi->header and rbi->footer fields. Normally, all of the insns for a function are part of a single linked list. Blocks are numbered sequentially, so it is always true that the last insn of block N is followed by the first insn of block N+1. If blocks N and N+1 are separated, then you are supposed to split the insn chain, and set rbi->footer for block N, and rbi->header for block N+1. These header/footer fields are used to reconnect the insn chain when the block movement is done. That is from a quick look, and may not be entirely accurate. I haven't done extensive work with this code.
I managed to isolate a case where moving a single BB would trigger this behaviour. (This is as far as I can tell by looking at the original code and matching BB's to source code positions. How do I get a dump of insns of a BB into some textual form? Is there a utility function for that?)
There are macros in the .gdbinit file that is automatically loaded by gdb. You can use pr to print a single instruction. E.g.
(gdb) print insn
(gdb) pr
You can use prl to print a list of N instructions. E.g.
(gdb) print debug_rtx_count = 1000
(gdb) print get_insns ()
(gdb) prl
will print 1000 instructions from the beginning of the function. This assumes that the insn-chain is intact, which isn't true during block reorg. You probably want to use something like BB_HEAD here.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
