Hi!
Sorry this took so long to come back to...
On Tue, Aug 25, 2020 at 02:39:56PM -0600, Jeff Law wrote:
> On Fri, 2020-08-07 at 21:51 +0000, Segher Boessenkool wrote:
> > When the compgotos pass copies the tail of blocks ending in an indirect
> > jump, there is a micro-optimization to not copy the last one, since the
> > original block will then just be deleted. This does not work properly
> > if cleanup_cfg does not merge all pairs of blocks we expect it to.
> >
> >
> > v2: This also deletes the other use of single_pred_p, which has the same
> > problem in principle, I just never have triggered it so far.
> >
> > Tested on powerpc64-linux {-m32,-m64} like before. Is this okay for
> > trunk?
> >
> >
> > Segher
> >
> >
> > 2020-08-07 Segher Boessenkool <seg...@kernel.crashing.org>
> >
> > PR rtl-optimization/96475
> > * bb-reorder.c (maybe_duplicate_computed_goto): Remove single_pred_p
> > micro-optimization.
> So this may have already been answered, but why didn't we merge the single
> pred
> with its single succ?
The patch makes the compgotos pass more robust, and also makes it work
in cases where the unmodified code would not (for example, with the
unmodified code, the original indirect jump is *not* copied to the
predecessors whenever possible).
I don't know if we hit this, or we hit a snag with some older GCC
releases that did not jump thread properly in all cases. I suspect a
micture of the two :-/
> Though I guess your patch wouldn't hurt, so OK.
Thanks!
Segher
