[PATCH] Fix undefined label problem after crossjumping (PR rtl-optimization/64536)

[Richard Biener]

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 <rguenther@suse.de>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Jennifer Guild,
Dilip Upmanyu, Graham Norton HRB 21284 (AG Nuernberg)