From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 71339 invoked by alias); 14 Dec 2015 08:57:16 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 71323 invoked by uid 89); 14 Dec 2015 08:57:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-qk0-f174.google.com Received: from mail-qk0-f174.google.com (HELO mail-qk0-f174.google.com) (209.85.220.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 14 Dec 2015 08:57:14 +0000 Received: by qkht125 with SMTP id t125so124828796qkh.3 for ; Mon, 14 Dec 2015 00:57:11 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.13.236.84 with SMTP id v81mr18264834ywe.263.1450083431525; Mon, 14 Dec 2015 00:57:11 -0800 (PST) Received: by 10.37.195.195 with HTTP; Mon, 14 Dec 2015 00:57:11 -0800 (PST) In-Reply-To: <1449877714.4788.113.camel@ubuntu-sellcey> References: <26dad41f-3c44-4b56-8ea1-ca3b7adbc053@BAMAIL02.ba.imgtec.org> <1449877714.4788.113.camel@ubuntu-sellcey> Date: Mon, 14 Dec 2015 08:57:00 -0000 Message-ID: Subject: Re: [RFC] Request for comments on ivopts patch From: Richard Biener To: sellcey@imgtec.com Cc: GCC Patches , amker cheng Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-12/txt/msg01363.txt.bz2 On Sat, Dec 12, 2015 at 12:48 AM, Steve Ellcey wrote: > On Wed, 2015-12-09 at 11:24 +0100, Richard Biener wrote: > >> > This second case (without the preference for the original IV) >> > generates better code on MIPS because the final assembly >> > has the increment instructions between the loads and the tests >> > of the values being loaded and so there is no delay (or less delay) >> > between the load and use. It seems like this could easily be >> > the case for other platforms too so I was wondering what people >> > thought of this patch: >> >> You don't comment on the comment you remove ... debugging >> programs is also important! >> >> So if then the cost of both cases should be distinguished >> somewhere else, like granting a bonus for increment before >> exit test or so. >> >> Richard. > > Here is new patch that tries to do that. It accomplishes the same thing > as my original patch but by checking different features. Basically, for > machines with no autoinc/autodec it has a preference for IVs that don't > change during loop (i.e. var_before == var_after). > > What do you think about this approach? > > Steve Ellcey > sellcey@imgtec.com > > > 2015-12-11 Steve Ellcey > > * tree-ssa-loop-ivopts.c (determine_iv_cost): Add cost to ivs that > need to be updated during loop. > > > diff --git a/gcc/tree-ssa-loop-ivopts.c b/gcc/tree-ssa-loop-ivopts.c > index 98dc451..ecf9737 100644 > --- a/gcc/tree-ssa-loop-ivopts.c > +++ b/gcc/tree-ssa-loop-ivopts.c > @@ -5826,6 +5826,14 @@ determine_iv_cost (struct ivopts_data *data, struct iv_cand *cand) > || DECL_ARTIFICIAL (SSA_NAME_VAR (cand->var_before))) > cost++; > > + /* If we are not using autoincrement or autodecrement, prefer ivs that > + do not have to be incremented/decremented during the loop. This can > + move loads ahead of the instructions that update the address. */ > + if (cand->pos != IP_BEFORE_USE > + && cand->pos != IP_AFTER_USE > + && cand->var_before != cand->var_after) > + cost++; > + I don't know enough to assess the effect of this but 1) not all archs can do auto-incdec so either the comment is misleading or the test should probably be amended 2) I wonder why with the comment ("during the loop") you exclude IP_NORMAL/END that said, the comment needs to explain the situation better. Of course all such patches need some code-gen effect investigation on more than one arch. [I wonder if a IV cost adjust target hook makes sense at some point] Richard. > /* Prefer not to insert statements into latch unless there are some > already (so that we do not create unnecessary jumps). */ > if (cand->pos == IP_END > >