From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 101012 invoked by alias); 7 Sep 2016 00:10:22 -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 100990 invoked by uid 89); 7 Sep 2016 00:10:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=H*p:D*org, H*r:10.1.1, HTo:U*Bin.Cheng X-HELO: mail-pa0-f42.google.com Received: from mail-pa0-f42.google.com (HELO mail-pa0-f42.google.com) (209.85.220.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 07 Sep 2016 00:10:10 +0000 Received: by mail-pa0-f42.google.com with SMTP id b2so7137837pat.2 for ; Tue, 06 Sep 2016 17:10:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=cPEUghF74bqB+n4Sspa3hXs6I3xqhOtLx4WfXbx232g=; b=fGCGO88+DuHffPU5DmuU+3N26ikYB7lZkSgLaGkzeRmnpbZPqrdL7y1/ZtOMKIJeOr bEeqsdEl8YBEBHGCQhNg3HRmUmjjOPOaYMy1iXtHYDZlVcGXij7KjqgjtrKyKYW0SDg7 ms/HI/TWTOk4RcnUu0E5Sd8HhfypuXL8X5J3kZ+BZ2HJDNT2L1M30wDpY7u46lknVJI2 oteNFpeY7g2duw2IXiDEpgUFGhpzWaGvpMETfB6VMvYHgjlErsBAFJ2rGnzQJ8E5KppM s6628hHHZFQS3XgBOBevdSbRTQEQ1IJq3optX8LqkYWcTflfA8jILFL/FcwRdbMafIiZ aKpQ== X-Gm-Message-State: AE9vXwPdsmVk62IcWsTiFuYZYwmuGzfMxuNzcM5vhxQBEPaKhzIxFABIMShyW7ENgfRSBWpG X-Received: by 10.66.127.38 with SMTP id nd6mr77534832pab.74.1473207008368; Tue, 06 Sep 2016 17:10:08 -0700 (PDT) Received: from [10.1.1.7] (58-6-183-210.dyn.iinet.net.au. [58.6.183.210]) by smtp.gmail.com with ESMTPSA id f62sm7206232pfj.75.2016.09.06.17.10.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Sep 2016 17:10:07 -0700 (PDT) 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: kugan Message-ID: <31d035f5-8258-ea71-e8f7-4697a78a3624@linaro.org> Date: Wed, 07 Sep 2016 00:21: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/msg00355.txt.bz2 Hi Bin, On 07/09/16 04:54, 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. > > > 009-prove-no_overflow-for-vect-niters-20160902.txt > > > diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c > index 0d37f55..2ef1f9b 100644 > --- a/gcc/tree-vect-loop.c > +++ b/gcc/tree-vect-loop.c > @@ -6610,6 +6610,38 @@ vect_loop_kill_debug_uses (struct loop *loop, gimple *stmt) > } > } > > +/* Given loop represented by LOOP_VINFO, return true if computation of > + LOOP_VINFO_NITERS (= LOOP_VINFO_NITERSM1 + 1) doesn't overflow, false > + otherwise. */ > + > +static bool > +loop_niters_no_overflow (loop_vec_info loop_vinfo) > +{ > + /* Constant case. */ > + if (LOOP_VINFO_NITERS_KNOWN_P (loop_vinfo)) > + { > + int cst_niters = LOOP_VINFO_INT_NITERS (loop_vinfo); Wouldn't it truncate by assigning this to int? > + tree cst_nitersm1 = LOOP_VINFO_NITERSM1 (loop_vinfo); > + > + gcc_assert (TREE_CODE (cst_nitersm1) == INTEGER_CST); > + if (wi::to_widest (cst_nitersm1) < cst_niters) Shouldn't you have do the addition and comparison in the type of the loop index instead of widest_int to see if that overflows? Thanks, Kugan > + return true; > + } > + > + widest_int max; > + struct loop *loop = LOOP_VINFO_LOOP (loop_vinfo); > + /* Check the upper bound of loop niters. */ > + if (get_max_loop_iterations (loop, &max)) > + { > + tree type = TREE_TYPE (LOOP_VINFO_NITERS (loop_vinfo)); > + signop sgn = TYPE_SIGN (type); > + widest_int type_max = widest_int::from (wi::max_value (type), sgn); > + if (max < type_max) > + return true; > + } > + return false; > +} > + > /* Function vect_transform_loop. > > The analysis phase has determined that the loop is vectorizable. > @@ -6697,8 +6729,9 @@ vect_transform_loop (loop_vec_info loop_vinfo) > tree niters = vect_build_loop_niters (loop_vinfo); > LOOP_VINFO_NITERS_UNCHANGED (loop_vinfo) = niters; > tree nitersm1 = unshare_expr (LOOP_VINFO_NITERSM1 (loop_vinfo)); > + bool niters_no_overflow = loop_niters_no_overflow (loop_vinfo); > vect_do_peeling (loop_vinfo, niters, nitersm1, &niters_vector, th, > - check_profitability, false); > + check_profitability, niters_no_overflow); > if (niters_vector == NULL_TREE) > { > if (LOOP_VINFO_NITERS_KNOWN_P (loop_vinfo)) > @@ -6707,7 +6740,7 @@ vect_transform_loop (loop_vec_info loop_vinfo) > LOOP_VINFO_INT_NITERS (loop_vinfo) / vf); > else > vect_gen_vector_loop_niters (loop_vinfo, niters, &niters_vector, > - false); > + niters_no_overflow); > } > > /* 1) Make sure the loop header has exactly two entries >