On Fri, 9 Jan 2015, Jakub Jelinek wrote: > 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.
Ah, indeed. > If you want, I can try instead of disabling it for tablejumps > just move the label. Yeah, I'd prefer that - it can't be too difficult, no? > 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. cfgcleanup material, similar for GIMPLE I guess. Richard. -- Richard Biener <rguent...@suse.de> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton HRB 21284 (AG Nuernberg)
