On Mon, 3 Jul 2017, Tom de Vries wrote:
> [ was: Re: [PATCH, PR81192] Don't tail-merge blocks from different loops ]
>
> On 07/03/2017 12:49 AM, Tom de Vries wrote:
> > [ was: Re: [PATCH, PR81192] Fix sigsegv in find_same_succ_bb ]
> >
> > On 07/03/2017 12:26 AM, Tom de Vries wrote:
> > > [ Trying again with before.svg instead of before.pdf ]
> > >
> > > Hi,
> > >
> > > consider this test-case:
> > > ...
> > > unsigned a;
> > > int b, c;
> > >
> > > static int
> > > fn1 (int p1, int p2)
> > > {
> > > return p1 > 2147483647 - p2 ? p1 : p1 + p2;
> > > }
> > >
> > > void
> > > fn2 (void)
> > > {
> > > int j;
> > > a = 30;
> > > for (; a;)
> > > for (; c; b = fn1 (j, 1))
> > > ;
> > > }
> > > ...
> > >
> > > When compiling the test-case with -Os, just before tail-merge it looks as
> > > in before.svg.
> > >
> > > During tail-merge, it runs into a sigsegv.
> > >
> > > What happens is the following:
> > > - tail-merge decides to merge blocks 4 and 6, and removes block 6.
> >
> > As pointed out in the PR, blocks 4 and 6 belong to different loops, and
> > shouldn't be merged.
> >
>
> While working on this PR, I used print_graph_cfg in tail-merge, which I
> noticed changes the choice in merging blocks. I tracked this down to:
> - mark_dfs_back_edges changing the EDGE_DFS_BACK flag on some edges, and
> - tail-merge requiring identical edge flags (apart from the true/false
> flags, which are dealt with explicitly).
>
> This is similar to PR69468 which notices the same about EDGE_EXECUTABLE.
>
> This patch allows more tail-merging by ignoring both EDGE_DFS_BACK and
> EDGE_EXECUTABLE. Consequently, in this example the two latch bbs (of the same
> loop) bb4 and bb7 are merged.
>
> Bootstrapped and reg-tested on x86_64.
>
> OK for trunk?
Ok.
Richard.
