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