This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix undefined label problem after crossjumping (PR rtl-optimization/64536)
- From: Richard Biener <rguenther at suse dot de>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Eric Botcazou <ebotcazou at adacore dot com>, Jeff Law <law at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Date: Fri, 9 Jan 2015 11:59:44 +0100 (CET)
- Subject: Re: [PATCH] Fix undefined label problem after crossjumping (PR rtl-optimization/64536)
- Authentication-results: sourceware.org; auth=none
- References: <20150109091014 dot GR1405 at tucnak dot redhat dot com> <alpine dot LSU dot 2 dot 11 dot 1501091031470 dot 12482 at zhemvz dot fhfr dot qr> <20150109095458 dot GS1405 at tucnak dot redhat dot com> <alpine dot LSU dot 2 dot 11 dot 1501091111070 dot 12482 at zhemvz dot fhfr dot qr> <20150109110014 dot GV1405 at tucnak dot redhat dot com>
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)