From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 33650 invoked by alias); 11 Dec 2015 23:48:41 -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 33630 invoked by uid 89); 11 Dec 2015 23:48:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mailapp01.imgtec.com Received: from mailapp01.imgtec.com (HELO mailapp01.imgtec.com) (195.59.15.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 11 Dec 2015 23:48:39 +0000 Received: from HHMAIL01.hh.imgtec.org (unknown [10.100.10.19]) by Websense Email Security Gateway with ESMTPS id 56BECF72F7805; Fri, 11 Dec 2015 23:48:32 +0000 (GMT) Received: from BAMAIL02.ba.imgtec.org (10.20.40.28) by HHMAIL01.hh.imgtec.org (10.100.10.19) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 11 Dec 2015 23:48:36 +0000 Received: from [10.20.3.214] (10.20.3.214) by bamail02.ba.imgtec.org (10.20.40.28) with Microsoft SMTP Server (TLS) id 14.3.174.1; Fri, 11 Dec 2015 15:48:34 -0800 Message-ID: <1449877714.4788.113.camel@ubuntu-sellcey> Subject: Re: [RFC] Request for comments on ivopts patch From: Steve Ellcey Reply-To: To: Richard Biener CC: GCC Patches , amker cheng Date: Fri, 11 Dec 2015 23:48:00 -0000 In-Reply-To: References: <26dad41f-3c44-4b56-8ea1-ca3b7adbc053@BAMAIL02.ba.imgtec.org> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-SW-Source: 2015-12/txt/msg01318.txt.bz2 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++; + /* 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