https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122218

--- Comment #3 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
gcc itself is not a good testcase? :)
I will try to construct this artificially.

I think the plan of not disambiguation loops will hit:


/* Initialize the loop structures we need, and finalize after.  */

unsigned int 
pass_ch::execute (function *fun)
{         
  loop_optimizer_init (LOOPS_NORMAL | LOOPS_HAVE_RECORDED_EXITS);
  scev_initialize ();

  unsigned int res = copy_headers (fun);

  scev_finalize (); 
  loop_optimizer_finalize ();
  return res;
}         

loop_ch later unloops loops:

      estimate_numbers_of_iterations (loop);
      if (!get_max_loop_iterations_int (loop))      
        {                                           
          if (dump_file && (dump_flags & TDF_DETAILS))
            fprintf (dump_file, "Loop %d never loops.\n", loop->num);
          scale_loop_profile (loop, profile_probability::always (), 0);
          loops_to_unloop.safe_push (loop);
          loops_to_unloop_nunroll.safe_push (0);
          continue;
        }

It also uses a latch block to detect do-while and treats them specially (in
particular when run in vectorization but then loops are disambiguate anyway).
Finally, latch is also used when updating the profile, but I can fix that for
multiple latches.

I added the unlooping, since I noticed that we have loops that never iterate in
code after early opts. I wonder if it perhaps fits better somewhere else, and
if so, perhaps we can avoid initialising SCEV?

Also. I noticed that
https://gcc.gnu.org/cgit/gcc/commit/?id=05e8ef2a05b477589cae25af3311bad0f68a90fe
moves process_loop_p check before unlooping with the comment:

      /* If the loop is already a do-while style one (either because it was
         written as such, or because jump threading transformed it into one),
         we might be in fact peeling the first iteration of the loop.  This
         in general is not a good idea.  Also avoid touching infinite loops. 
*/

I think that this is not correct about unlooping of never iterating loops (that
does no duplication at all). So perhaps we give up a bit too early now? In
general, I think loop-ch is the only place capable of partial peeling (I think
jump threaders disable themselves) that is probably useful for all kinds of
loops having likely early exit, including ones that pass the do-while check.

Reply via email to