On Fri, Jan 09, 2015 at 11:15:14AM +0100, Richard Biener wrote: > On Fri, 9 Jan 2015, Jakub Jelinek wrote: > > > On Fri, Jan 09, 2015 at 10:36:09AM +0100, Richard Biener wrote: > > > I wonder why post_order_compute calls tidy_fallthru_edges at all - won't > > > that break the just computed postorder? > > > > Dunno, but I think it shouldn't break anything, the function doesn't remove > > any blocks, just in the typical case of an unconditional jump to the next bb > > or conditional jump to the next bb (if only successor) removes the jump and > > makes the edge EDGE_FALLTHRU. > > > > > Other than that, why doesn't can't the issue show up with non-table-jumps? > > > > I think tablejumps are the only case where (at least during jump2) > > code_labels live in between the basic blocks, not inside of them. > > > > > What does it take to preserve (all) the labels? > > > > Then we'd need to remove all the instructions in between the two basic > > blocks (as we currently do), but move any code_labels from there first to > > the start of the next basic block. Probably better just call tablejump_p > > with non-NULL args and move precisely that code_label that it sets. > > > > But, as I said, we'd still not optimize it if tidy_fallthru_edges is not > > called, so we'd need to do it at another place too. > > Ok, I see. I still wonder why we call tidy_fallthru_edges from > postorder_compute. If we delete unreachable blocks that means > we at most remove incoming edges to a block - that should never > change any other edges fallthru status...?
The call has been added by http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00095.html and is only done if post_order_compute is called with the special flag, supposedly that replaced explicit delete_unreachable_blocks or similar. And, if you remove unreachable blocks, if they are in between some bb and its single successor, then indeed that is something that should be tidied, as we don't have to jump around nothing. If you want, I can try instead of disabling it for tablejumps just move the label. Still, I think we should be able to optimize it somewhere else too (we can remove the tablejumps not just if all jump_table_data entries point to next_bb, but even when they point to some completely different bb, as long as it is a single_succ_p). And ideally also optimize it at GIMPLE, but guess that is GCC 6 material. Jakub
