From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12689 invoked by alias); 23 Jun 2017 10:24:56 -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 12648 invoked by uid 89); 23 Jun 2017 10:24:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=foul X-HELO: mail-ua0-f176.google.com Received: from mail-ua0-f176.google.com (HELO mail-ua0-f176.google.com) (209.85.217.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 23 Jun 2017 10:24:53 +0000 Received: by mail-ua0-f176.google.com with SMTP id z22so34132153uah.1 for ; Fri, 23 Jun 2017 03:24:52 -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=AK79JjYKnpxTC+psUdDrmLR0onr/4R4SHiejiSPK5BM=; b=EqXxremeu2ZU/N7Mk/TpBwN3QuQCr6PcP2waNyPlOOjfWwWdcym62UCN1+57juXB3Y ALoQB0YCNxzbXa9mDmcE215oexKBIm6HFNfOEkZ3Hcjj+tyTVl3evnuLAR+41pNBmIRA vRQHK5Gqra4C4f4h5ABrWY5zLKg7w7V5+9FuLK1Woy11sBMEwsn/6SVjn0MIR0hkpMQE wSHQaZs76+sYfjaP0Z9WDv/02mAbntd8CTGkTYz/vfPmuWmno7UDWhzjJ19oRjCT/kGx Kw1blDSFqnBTfJJg113MvlctUxOdPoRlKAbTMiME3tlb9vy0KUiNni6VRZUqXn34ynvP YaYQ== X-Gm-Message-State: AKS2vOwU3ub2m5e6aLbkJmJsDbwymRE/H2aJxDYMItV97hyHz9XynpPx G95VRbsgdLMPDcB1iutyr2kDpEkdXw== X-Received: by 10.176.76.96 with SMTP id d32mr4562223uag.4.1498213491299; Fri, 23 Jun 2017 03:24:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.49.142 with HTTP; Fri, 23 Jun 2017 03:24:50 -0700 (PDT) In-Reply-To: References: From: "Bin.Cheng" Date: Fri, 23 Jun 2017 10:24:00 -0000 Message-ID: Subject: Re: [PATCH GCC][11/13]Annotate partition by its parallelism execution type To: Richard Biener Cc: "gcc-patches@gcc.gnu.org" Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-06/txt/msg01756.txt.bz2 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? 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.