From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 84447 invoked by alias); 12 Sep 2016 19:58:31 -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 84429 invoked by uid 89); 12 Sep 2016 19:58:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Prove, peeled, Bin X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 12 Sep 2016 19:58:20 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7BD0066846; Mon, 12 Sep 2016 19:58:19 +0000 (UTC) Received: from localhost.localdomain (ovpn-116-111.phx2.redhat.com [10.3.116.111]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8CJwIIY019401; Mon, 12 Sep 2016 15:58:19 -0400 Subject: Re: [PATCH GCC 9/9]Prove no-overflow in computation of LOOP_VINFO_NITERS and improve code generation To: Bin Cheng , "gcc-patches@gcc.gnu.org" References: Cc: nd From: Jeff Law Message-ID: <556100e4-1813-16da-de42-5857c7470bd0@redhat.com> Date: Mon, 12 Sep 2016 20:00:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-09/txt/msg00664.txt.bz2 On 09/06/2016 12:54 PM, Bin Cheng wrote: > Hi, > LOOP_VINFO_NITERS is computed as LOOP_VINFO_NITERSM1 + 1, which could overflow in loop niters' type. Vectorizer needs to generate more code computing vectorized niters if overflow does happen. However, For common loops, there is no overflow actually, this patch tries to prove the no-overflow information and use that to improve code generation. At the moment, no-overflow information comes either from loop niter analysis, or the truth that we know loop is peeled for non-zero iterations in prologue peeling. For the latter case, it doesn't matter if the original LOOP_VINFO_NITERS overflows or not, because computation LOOP_VINFO_NITERS - LOOP_VINFO_PEELING_FOR_ALIGNMENT cancels the overflow by underflow. > > Thanks, > bin > > 2016-09-01 Bin Cheng > > * tree-vect-loop.c (loop_niters_no_overflow): New func. > (vect_transform_loop): Call loop_niters_no_overflow. Pass the > no-overflow information to vect_do_peeling_for_loop_bound and > vect_gen_vector_loop_niters. > OK when prereqs are all approved. jeff