[Bug rtl-optimization/72855] Long compile time due to integrity checking during dataflow analysis per loop

["amker at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #3 from amker at gcc dot gnu.org ---
(In reply to amker from comment #1)
> Among all loops in the large function, how many loops can be doloop
> optimized successfully?  Function doloop__optimize has some valid checks on
> doloop optimizations.  Is it possible to move most (some) of checks outside
> of the per-loop function.  Looks like targetm.invalid_within_doloop can be
> moved.  As a result, we can know some loops can't be doloop optimized, so
> the iv_analysis/df_analysis can be skipped for those loops.  For checks on
> loop analysis result:
>   if (!desc->simple_p
>       || desc->assumptions
>       || desc->infinite)
> I think it's possible to avoid per-loop analysis behavior too.  Since we
> don't change code, there is no need to do df analysis for each loop before
> iv_analysis.  As a result, df_verify can be saved.  We may need a new
> interface analyzing iv/loop_desc for all loops in loop-iv.c
> 
> Of course, if most loops can be doloop optimized, this may not be able to
> help.

As suspected, most loop can't be doloop optimized by the target dependent insn
check.  I am testing a simple refactoring patch to see if it can reduce compile
time.