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...? Does just removing that call there work and make the bug latent again? Richard. -- Richard Biener <rguent...@suse.de> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton HRB 21284 (AG Nuernberg)
