From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 56596 invoked by alias); 23 Jun 2017 11:04:58 -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 56581 invoked by uid 89); 23 Jun 2017 11:04:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-oi0-f47.google.com Received: from mail-oi0-f47.google.com (HELO mail-oi0-f47.google.com) (209.85.218.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 23 Jun 2017 11:04:56 +0000 Received: by mail-oi0-f47.google.com with SMTP id p187so23540588oif.3 for ; Fri, 23 Jun 2017 04:04:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FMe2IjcZvGajMI33/6PiEi+LG7LTrFIOS6Uuti66pIk=; b=bg1wHQZTGRfVNx7S5/ggGQSCzophBEF4kLlk0sn7C9nGJ90njdVugQgh93iKdvQCPD B770F/MQYz3fhkF3hgefnNtJs+bj5gHFhpCj919X6l5rDWHTOD7+DmlVez3wiUJvSMWZ 2gVzvFJiDoQQsoZAPTK5cmJ//GosBT4ioAEHGd2V69UtFekv+OmWVeV7MU6NA7lGVHpz ELM4lA2iyf3DNXbjHS2xmsbpvHbp/UeR+JhNrfCUAnfgHBdgeZX345tmBktFIECfDejw 3Kqv47QcEkRXsYSD7CehJ6G53gWVyq7DNcR5z7+AyvpwuIbke73LBeODErKXrrp5NEn3 HNcw== X-Gm-Message-State: AKS2vOwO1X4P65Zg5KupNNqMioNDOUB9vDO9pJVORuOTA2QyPk9ModKq t0Bw02dBAWIuTZgfH6UxUm1ZOsBHEw== X-Received: by 10.202.237.133 with SMTP id l127mr550997oih.128.1498215894635; Fri, 23 Jun 2017 04:04:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.37.66 with HTTP; Fri, 23 Jun 2017 04:04:53 -0700 (PDT) In-Reply-To: References: <71dace72-d755-8519-fde4-5dd382641192@redhat.com> <8ff0a98e-4de5-564e-f162-3f230188dbc5@redhat.com> From: Richard Biener Date: Fri, 23 Jun 2017 11:04:00 -0000 Message-ID: Subject: Re: [PATCH GCC][5/5]Enable tree loop distribution at -O3 and above optimization levels. To: "Bin.Cheng" Cc: Jeff Law , "gcc-patches@gcc.gnu.org" Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-06/txt/msg01770.txt.bz2 On Fri, Jun 23, 2017 at 10:47 AM, Bin.Cheng wrote: > On Fri, Jun 23, 2017 at 6:04 AM, Jeff Law wrote: >> On 06/07/2017 02:07 AM, Bin.Cheng wrote: >>> On Tue, Jun 6, 2017 at 6:47 PM, Jeff Law wrote: >>>> On 06/02/2017 05:52 AM, Bin Cheng wrote: >>>>> Hi, >>>>> This patch enables -ftree-loop-distribution by default at -O3 and above optimization levels. >>>>> Bootstrap and test at O2/O3 on x86_64 and AArch64. is it OK? >>>>> >>>>> Note I don't have strong opinion here and am fine with either it's accepted or rejected. >>>>> >>>>> Thanks, >>>>> bin >>>>> 2017-05-31 Bin Cheng >>>>> >>>>> * opts.c (default_options_table): Enable OPT_ftree_loop_distribution >>>>> for -O3 and above levels. >>>> I think the question is how does this generally impact the performance >>>> of the generated code and to a lesser degree compile-time. >>>> >>>> Do you have any performance data? >>> Hi Jeff, >>> At this stage of the patch, only hmmer is impacted and improved >>> obviously in my local run of spec2006 for x86_64 and AArch64. In long >>> term, loop distribution is also one prerequisite transformation to >>> handle bwaves (at least). For these two impacted cases, it helps to >>> resolve the gap against ICC. I didn't check compilation time slow >>> down, we can restrict it to problem with small partition number if >>> that's a problem. >> Just a note. I know you've iterated further with Richi -- I'm not >> objecting to the patch, nor was I ready to approve. >> >> Are you and Richi happy with this as-is or are you looking to submit >> something newer based on the conversation the two of you have had? > Hi Jeff, > The patch series is updated in various ways according to review > comments, for example, it restricts compilation time by checking > number of data references against MAX_DATAREFS_FOR_DATADEPS as well as > restores data dependence cache. There are still two missing parts I'd > like to do as followup patches: one is loop nest distribution and the > other is a data-locality cost model (at least) for small cases. Now > Richi approved most patches except the last major one, but I still > need another iterate for some (approved) patches in order to fix > mistake/typo introduced when I separating the patch. The patch is ok after the approved parts of the ldist series has been committed. Note your patch lacks updates to invoke.texi (what options are enabled at -O3). Please adjust that before committing. Thanks, Richard. > Thanks, > bin >> >> jeff