On 01/08/2016 11:05 PM, Bernd Schmidt wrote:
On 01/08/2016 10:23 PM, Jakub Jelinek wrote:
Now, the merge_if_block caller removes the simple_return from the then_bb
in preparation of the merge and expects the two bbs to be merged
together,
I'd be tempted to remove the barrier as well at this point. It does look
like the cfgrtl code tries to handle isolated barriers, but IMO it's
poor practice given that it's easy to avoid here.
Well, I checked a bit more. Most callers of merge_blocks seem to already
look for barriers if they are a concern and remove them. This occurs
multiple times in ifcvt.c and cfgcleanup.c. Oddly,
merge_blocks_move_predecessor_nojumps uses next_nonnote_insn to find the
barrier, while merge_blocks_move_successor_nojumps uses just NEXT_INSN.
That should probably be fixed too.
So the situation is a bit odd in that most callers remove the barrier
but merge_blocks tries to handle an isolated barrier as well. The area
could probably cleaned up a little, but on the whole I still lean
towards requiring the caller to remove an isolated barrier. That leaves
the RTL in a more consistent state before the call to merge_blocks.
Bernd
