From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 452 invoked by alias); 12 Feb 2015 11:02:01 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 442 invoked by uid 89); 12 Feb 2015 11:02:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mailout06.t-online.de Received: from mailout06.t-online.de (HELO mailout06.t-online.de) (194.25.134.19) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 12 Feb 2015 11:01:58 +0000 Received: from fwd09.aul.t-online.de (fwd09.aul.t-online.de [172.20.27.151]) by mailout06.t-online.de (Postfix) with SMTP id 7EEC0F170F; Thu, 12 Feb 2015 12:01:54 +0100 (CET) Received: from [192.168.0.106] (rXYMJaZSghgtPlQSZ6U+TbLziOZzm1HPtayaFVYnj2Mm-sMnyBzoYfsOlT3KlvaQBT@[84.183.240.30]) by fwd09.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1YLrWj-0HwZsW0; Thu, 12 Feb 2015 12:01:45 +0100 Message-ID: <1423738904.18129.1.camel@yam-132-YW-E178-FTW> Subject: Re: Unrolling factor heuristics for Loop Unrolling From: Oleg Endo To: Ajit Kumar Agarwal Cc: "gcc@gcc.gnu.org" , Vinod Kathail , Shail Aditya Gupta , Vidhumouli Hunsigida , Nagaraju Mekala Date: Thu, 12 Feb 2015 11:02:00 -0000 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-IsSubscribed: yes X-SW-Source: 2015-02/txt/msg00090.txt.bz2 On Thu, 2015-02-12 at 10:09 +0000, Ajit Kumar Agarwal wrote: > Hello All: > > The Loop unrolling without good unrolling factor heuristics becomes the performance bottleneck. The Unrolling factor heuristics based on minimum > Initiation interval is quite useful with respect to better ILP. The minimum Initiation interval based on recurrence and resource calculation on Data > Dependency Graph along with the register pressure can be used to add the unrolling factor heuristics. To achieve better ILP with the given schedule, > the Loops unrolling and the scheduling are inter dependent and has been widely used in Software Pipelining Literature along with the more granular > List and Trace Scheduling. > > The recurrence calculation based on the Loop carried dependencies and the resource allocation based on the simultaneous access of the resources > Using the reservation table will give good heuristics with respect to calculation of unrolling factor. This has been taken care in the > MII interval Calculation. > > Along with MII, the register pressure should also be considered in the calculation of heuristics for unrolling factor. > > This enable better heuristics with respect to unrolling factor. The main advantage of the above heuristics for unrolling factor is that it can be > Implemented in the Code generation Level. Currently Loop unrolling is done much before the code generation. Let's go by the current implementation > Of doing Loop unrolling optimization at the Loop optimizer level and unrolling happens. After the Current unrolling at the optimizer level the above heuristics > Can be used to do the unrolling at the Code generation Level with the accurate Register pressure calculation as done in the register allocator and the > Unrolling is done at the code generation level. This looks feasible solution which I am going to propose for the above unrolling heuristics. > > This enables the Loop unrolling done at the Optimizer Level + at the Code Generation Level. This double level of Loop unrolling is quite useful. > This will overcome the shortcomings of the Loop unrolling at the optimizer level. > > The SPEC benchmarks are the better candidates for the above heuristics instead of Mibench and EEMBC. Not taking register pressure into account when unrolling (and doing other optimizations/choices) is an old problem. See also: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20969 Cheers, Oleg