[PATCH] Fix up orig_loop_num handling during move_sese_region_to_fn (PR tree-optimization/81945)

[Jakub Jelinek]

On Wed, Dec 06, 2017 at 07:54:21AM +0100, Richard Biener wrote:
> On December 5, 2017 10:05:43 PM GMT+01:00, Jakub Jelinek <jakub@redhat.com> wrote:
> >Hi!
> >
> >move_sese_region_to_fn moves a subset of the original loop tree
> >to the dest_cfun (and adds the outermost loop new).
> >Now, some loops might have non-zero orig_loop_num field.  In the caller
> >that is fine, if the orig_loop_num loop is moved, then get_loop will
> >just
> >return NULL and we'll clear it later.  But if a loop with orig_loop_num
> >!= 0
> >is moved into the dest_cfun, where we create new numbers for the loops,
> >orig_loop_num might be too large for the larray vector, or might point
> >to an unrelated loop.
> >
> >The following patch goes through all the loops moved into dest_cfun and
> >if
> >they have non-zero orig_loop_num, it tries to remap them into a new
> >number
> >if it points to a loop that was also moved to dest_cfun, or clears it
> >otherwise.
> >
> >Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> OK.  I suppose if we ever encounter this in inlining we need sth similar there. 

Indeed, in inlining or fnsplit.  But right now it is only ldist pass that
sets this to non-zero and so it shouldn't affect any of the IPA or pre-IPA
passes.

	Jakub