Re: [PATCH] Clean-up orphaned NOTE_INSN_LOOP_CONT notes

[Jeff Law <law at porcupine dot slc dot redhat dot com>]

In message <Pine.LNX.4.33.0209081415490.32096-100000@www.eyesopen.com>, Roger S
ayle writes:
 >
 >In two recent examples, I've come across orphaned NOTE_INSN_LOOP_CONT
 >notes whilst examining the output.  These are generated by infinite
 >loop constructs like "for(;;) {...}" or "while(1) {...}" which may
 >be generated as
 >
 >;; NOTE_INSN_LOOP_BEG
 >L1:	...
 >	Jmp L2
 >
 >;; NOTE_INSN_LOOP_CONT
 >L2:	Jmp L1
 >;; NOTE_INSN_LOOP_END
 >
 >Control flow optimization then starts recognizing the unconditional
 >branches to an unconditional branch, and jump threading redirects
 >all references to L2 to L1.  Finally dead code elimination spots
 >that L2's basic block in unreachable and deletes the basic block.
 >With this current mainline produces:
 >
 >;; NOTE_INSN_LOOP_BEG
 >L1:	...
 >	Jmp L1
 >
 >;; NOTE_INSN_LOOP_CONT
 >;; NOTE_INSN_LOOP_END
 >
 >The NOTE_INSN_LOOP_CONT has become orphaned as it isn't deleted
 >when the label it annotates is destroyed.  This note is no longer
 >useful to the loop optimization pass, for example it isn't even
 >inside the loop!  This was a contributing factor in PR opt/6405.
 >I suspect its also the cause of problems for another patch I'm
 >working on.
 >
 >The patch below cleans up the NOTE_INSN_LOOP_CONT notes when its
 >parent basic block is deleted and the label it annotates is destroyed.
 >
 >This patch has survived a complete "make bootstrap" and "make -k
 >check" on i686-pc-linux-gnu, all languages except Ada and treelang,
 >with no new regressions.
 >
 >Ok for mainline or the gcc-3_4-basic-improvements-branch?
 >
 >
 >2002-09-08  Roger Sayle  <roger@eyesopen.com>
 >
 >	* cfgrtl.c (flow_delete_block_noexpunge): Delete orphaned
 >	NOTE_INSN_LOOP_CONT notes when deleting basic blocks.
I went ahead and checked this in.  It simplifies some stuff I'm investigating
at the moment.

jeff