[Bug rtl-optimization/55190] [SH] ivopts causes loop setup bloat

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

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55190

--- Comment #4 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to bin.cheng from comment #3)
> ARM can benefit from doloop structure too, but it is implemented in
> different way. ARM backend defines special addsi_compare pattern and let
> combine pass combine decrement and comparison instruction, thus saving the
> comparison instruction.
> 
> IVOPT can be improved to select two iv candidates for the example loop, with
> auto-increment one for the memory access and decrement one for loop exit
> check.  This is especially good for target supports both doloop and
> auto-increment instructions like ARM and SH.

Yes, probably addressing mode selection for memories inside the loop can be
covered somehow by ivopt.  However, this PR is about the calculations of the
loop counter and the handling of overflows.

> 
> BUT most hand-written loops have incremental basic iv, so IVOPT depends on
> previous pass ivcanon to rewrite it into decremental iv, like below:
> 
> for (i = 0; i < 100; i++)
>   //loop body
> 
> ---->
> for (i = 100; i > 0; i--)
>   //modified loop body
> 
> Unfortunately, ivcanon pass only do such loop transformation for loop which
> iterates constant number times.
> 
> It seems difficult for RTL loop passes to revert decision made by IVOPT, so
> I think it should be done in GIMPLE IVOPT. I will give it a try.

I think this is a another story of missed ivopt opportunities.  Maybe open a
new PR for this?