From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14367 invoked by alias); 16 Jun 2016 05:06:29 -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 14356 invoked by uid 89); 16 Jun 2016 05:06:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=enkovich.gnu@gmail.com, enkovichgnugmailcom, Hx-languages-length:1917 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 16 Jun 2016 05:06:27 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (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 4218664D25; Thu, 16 Jun 2016 05:06:26 +0000 (UTC) Received: from localhost.localdomain (ovpn-116-111.phx2.redhat.com [10.3.116.111]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u5G56PET023156; Thu, 16 Jun 2016 01:06:26 -0400 Subject: Re: [PATCH, vec-tails 01/10] New compiler options To: Ilya Enkovich , Richard Biener References: <20160519193619.GB40563@msticlxl57.ims.intel.com> Cc: GCC Patches From: Jeff Law Message-ID: <7ac2a8d9-0031-cdd0-17d2-7c00284e9e09@redhat.com> Date: Thu, 16 Jun 2016 05:06:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-06/txt/msg01196.txt.bz2 On 05/20/2016 05:40 AM, Ilya Enkovich wrote: > 2016-05-20 14:17 GMT+03:00 Richard Biener : >> On Fri, May 20, 2016 at 11:50 AM, Ilya Enkovich wrote: >>> 2016-05-20 12:26 GMT+03:00 Richard Biener : >>>> On Thu, May 19, 2016 at 9:36 PM, Ilya Enkovich wrote: >>>>> Hi, >>>>> >>>>> This patch introduces new options used for loop epilogues vectorization. >>>> >>>> Why's that? This is a bit too much for the casual user and if it is >>>> really necessary >>>> to control this via options then it is not fine-grained enough. >>>> >>>> Why doesn't the vectorizer/backend have enough info to decide this itself? >>> >>> I don't expect casual user to decide which modes to choose. These controls are >>> added for debugging and performance measurement purposes. I see now I miss >>> -ftree-vectorize-epilogues aliased to -ftree-vectorize-epilogues=all. Surely >>> I expect epilogues and short loops vectorization be enabled by default on -O3 >>> or by -ftree-vectorize-loops. >> >> Can you make all these --params then? I think to be useful to users we'd want >> them to be loop pragmas rather than options. > > OK, I'll change it to params. I didn't think about control via > pragmas but will do now. So the questions I'd like to see answered: 1. You've got 3 modes for epilogue vectorization. Is this an artifact of not really having good heuristics yet for which mode to apply to a particular loop at this time? 2. Similarly for cost models. In the cover message you indicated you were getting expected gains of KNL, but not on Haswell. Do you have any sense yet why you're not getting good resuls on Haswell yet? For KNL are you getting those speedups with a generic set of options or are those with a custom set of options to set the mode & cost models? jeff