From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 88090 invoked by alias); 23 Jun 2017 10:49:12 -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 87756 invoked by uid 89); 23 Jun 2017 10:49:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 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-ot0-f176.google.com Received: from mail-ot0-f176.google.com (HELO mail-ot0-f176.google.com) (74.125.82.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 23 Jun 2017 10:49:07 +0000 Received: by mail-ot0-f176.google.com with SMTP id 95so28934484ott.3 for ; Fri, 23 Jun 2017 03:49:07 -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=oyAu9uuc6cKaWvZDDx3eUVsd5r7VL36sokyh+9VpCtI=; b=dVCtLNq7xrTASd0g3w2CoJQkscR6hqgaimUP1sSuBc6mpE+3A2uNhbbkFak2AYEZE5 3mnGr/1xDFjJUsdo3cCNTx2rmeE01g+R7U+ETtGOkG2McGhYfPDrUAo2olJeyMMifKJE 8HOdGkbHAxHrD1eUEZfWesdskXFWodH/GOakraGv6YGMtsfqRtKULcYXYC6Rq2qgOTg8 LtuSJxIuBEXHXx85JjLEpoE2+6AsmqTNaOx0Zwn5ti0FHvQTjK0EPKZVxwP7nRtCnz1O NTwVapxAEG6g+PtIbt5ki2u1KenZkHe8saeW/quGe7fa5kNXooT7Em8qoqAqK0tkDO/U PF9A== X-Gm-Message-State: AKS2vOxdivx1y8YNamL8wb32XfJwxzkcXm4GLk7G/Jbk1mMhQUwVY3SS iWyGeVEcq1Vr8aLMSUHbWVS142CG3g== X-Received: by 10.157.38.164 with SMTP id l33mr4464978otb.197.1498214946384; Fri, 23 Jun 2017 03:49:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.37.66 with HTTP; Fri, 23 Jun 2017 03:49:05 -0700 (PDT) In-Reply-To: References: From: Richard Biener Date: Fri, 23 Jun 2017 10:49:00 -0000 Message-ID: Subject: Re: [PATCH GCC][11/13]Annotate partition by its parallelism execution type To: "Bin.Cheng" Cc: "gcc-patches@gcc.gnu.org" Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-06/txt/msg01764.txt.bz2 On Fri, Jun 23, 2017 at 12:25 PM, Bin.Cheng wrote: > And the patch. > > On Fri, Jun 23, 2017 at 11:24 AM, Bin.Cheng wrote: >> On Tue, Jun 20, 2017 at 12:34 PM, Richard Biener >> wrote: >>> On Tue, Jun 20, 2017 at 11:18 AM, Bin.Cheng wrote: >>>> On Fri, Jun 16, 2017 at 11:10 AM, Richard Biener >>>> wrote: >>>>> On Mon, Jun 12, 2017 at 7:03 PM, Bin Cheng wrote: >>>>>> Hi, >>>>>> This patch checks and records if partition can be executed in parallel by >>>>>> looking if there exists data dependence cycles. The information is needed >>>>>> for distribution because the idea is to distribute parallel type partitions >>>>>> away from sequential ones. I believe current distribution doesn't work >>>>>> very well because it does blind distribution/fusion. >>>>>> Bootstrap and test on x86_64 and AArch64. Is it OK? >>>>> >>>>> + /* In case of no data dependence. */ >>>>> + if (DDR_ARE_DEPENDENT (ddr) == chrec_known) >>>>> + return false; >>>>> + /* Or the data dependence can be resolved by compilation time alias >>>>> + check. */ >>>>> + else if (!alias_sets_conflict_p (get_alias_set (DR_REF (dr1)), >>>>> + get_alias_set (DR_REF (dr2)))) >>>>> + return false; >>>>> >>>>> dependence analysis should use TBAA already, in which cases do you need this? >>>>> It seems to fall foul of the easy mistake of not honoring GCCs memory model >>>>> as well ... see dr_may_alias_p. >>>> I see. Patch updated with this branch removed. >>>> >>>>> >>>>> + /* Further check if any data dependence prevents us from executing the >>>>> + partition parallelly. */ >>>>> + EXECUTE_IF_SET_IN_BITMAP (partition->reads, 0, i, bi) >>>>> + { >>>>> + dr1 = (*datarefs_vec)[i]; >>>>> + EXECUTE_IF_SET_IN_BITMAP (partition->writes, 0, j, bj) >>>>> + { >>>>> >>>>> what about write-write dependences? >>>>> >>>>> + EXECUTE_IF_SET_IN_BITMAP (partition->reads, 0, i, bi) >>>>> + { >>>>> + dr1 = (*datarefs_vec)[i]; >>>>> + EXECUTE_IF_SET_IN_BITMAP (partition->writes, i + 1, j, bj) >>>>> + { >>>>> + dr2 = (*datarefs_vec)[j]; >>>>> + /* Partition can only be executed sequentially if there is any >>>>> + data dependence cycle. */ >>>>> >>>>> exact copy of the loop nest follows?! Maybe you meant to iterate >>>>> over writes in the first loop. >>>> Yes, this is a copy-paste typo. Patch is also simplified because >>>> read/write are recorded together now. Is it OK? >>> >>> Ok. >> Sorry I have to update this patch because one of my mistake. I didn't >> update partition type when fusing them. For some partition fusion, >> the update is necessary otherwise we end up with inaccurate type and >> inaccurate fusion later. Is it Ok? Ok. >> Thanks, >> bin >> 2017-06-20 Bin Cheng >> >> * tree-loop-distribution.c (enum partition_type): New. >> (struct partition): New field type. >> (partition_merge_into): Add parameter. Update partition type. >> (data_dep_in_cycle_p, update_type_for_merge): New functions. >> (build_rdg_partition_for_vertex): Compute partition type. >> (rdg_build_partitions): Dump partition type. >> (distribute_loop): Update calls to partition_merge_into.