https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67778
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
But it is shrink-wrapping that inserts the prologue into the loop.
Before pro_and_epilogue we have cfg like:
ENTRY
|
bb2
/ \
v v<----+
bb3 bb4 \
| \ \
v<+ \ \
bb5 \ \ \
/ \ \ \ \
v<+ v \ \ \
bb6| bb7 | \ \
| | / \ | | |
+-+ | +-+ | |
v | |
bb8 | |
| v |
+-------> bb9 |
/ \ |
v +---+
bb10
|
v
EXIT
and the only bb that needs prologue is bb10.
The changes that pro_and_epilogue pass does are:
1) the bb4 -> bb9 edge, previously DFS_BACK,IRREDUCIBLE_LOOP, looses both of
those flags
2) prologue is inserted at the beginning of bb9
3) epilogue (ending with (simple_return) is inserted at the end of bb10
4) a barrier is inserted after that (simple_return)
I don't see any other changes. Please have a look at the dumps.
Multiple paths to the same bb having different CFI info are a direct
consequence of this bug, because bb9 is then reachable from the CFI info at the
beginning of function (when reached from bb8 or bb2->bb4) and CFI info after
prologue (when reached from bb9->bb4). What code in the shrink-wrapping bb
discovery rewrite is supposed to make sure that the prologue is not put into
the middle of a loop?
