From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-431004-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 32486 invoked by alias); 3 Oct 2013 10:00:53 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Received: (qmail 32431 invoked by uid 48); 3 Oct 2013 10:00:50 -0000
From: "olegendo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/55190] [SH] ivopts causes loop setup bloat
Date: Thu, 03 Oct 2013 10:00:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 4.8.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: olegendo at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-55190-4-lxh3mh03lx@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-55190-4@http.gcc.gnu.org/bugzilla/>
References: <bug-55190-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-10/txt/msg00148.txt.bz2

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?