From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 122733 invoked by alias); 18 Jan 2017 14:55:07 -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 122711 invoked by uid 89); 18 Jan 2017 14:55:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=Combination, Loads-only, Loadsonly, H*f:sk:2b98654 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-oi0-f44.google.com Received: from mail-oi0-f44.google.com (HELO mail-oi0-f44.google.com) (209.85.218.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 18 Jan 2017 14:54:57 +0000 Received: by mail-oi0-f44.google.com with SMTP id j15so7962716oih.2; Wed, 18 Jan 2017 06:54:56 -0800 (PST) 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:content-transfer-encoding; bh=fYhjUvjZIGYDQggdNas/IbH9SJmxn9kGFKO67QlwqBk=; b=uEB8dCNqvmOpCnHb0PnWaZ4H4Pq+hBxy1QZfRGLK9U0cuP+ISP4LGmP6rtUnnoEKPN W8UqNMaiNhtcH0ORLf22V8RX6ES6FFHc5ytnkGAerLk/ShUncrRZRTbnCsHnJQcetZE9 lVA0UMGlJeXnT03gIZwlYO6NYLjdWp30JfSyKHOJdHdesbvC+oj1D7O8MJqt6jfaUyTp cC2Mt/EPQymayYGXGK3JIO5cn8NzWXrap3E1SNavJ1nsRcrUwVJeIttMf2zBpRiKnlDy R93ofUiANPzPUgTpyBaKKLg4xrqhtpuUx00rGFec7Hr2BaEcZzZQrI2SDV218UFz1lud u23Q== X-Gm-Message-State: AIkVDXIbZYUjpU4a3yPnZ/ZLlXxnX9URyKyMBGYkts/sO3ogn6lz5M0wQlGapKOHqWeCarjdIOKO7jRoCOz5Iw== X-Received: by 10.202.94.194 with SMTP id s185mr1890668oib.196.1484751295469; Wed, 18 Jan 2017 06:54:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.42.12 with HTTP; Wed, 18 Jan 2017 06:54:55 -0800 (PST) In-Reply-To: <2b986549-702b-2a09-84d5-e3f93518e4c3@suse.cz> References: <2b986549-702b-2a09-84d5-e3f93518e4c3@suse.cz> From: Richard Biener Date: Wed, 18 Jan 2017 14:59:00 -0000 Message-ID: Subject: Re: [PATCH] Be careful about combined chain with length == 0 (PR, tree-optimization/70754). To: =?UTF-8?Q?Martin_Li=C5=A1ka?= Cc: GCC Patches , vp@gcc.gnu.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-01/txt/msg01338.txt.bz2 On Wed, Jan 18, 2017 at 11:10 AM, Martin Li=C5=A1ka wrote: > Hello. > > After basic understanding of loop predictive commoning, the problematic c= ombined chain is: > > Loads-only chain 0x38b6730 (combined) > max distance 0 > references: > MEM[(real(kind=3D8) *)vectp_a.29_81] (id 1) > offset 20 > distance 0 > MEM[(real(kind=3D8) *)vectp_a.38_141] (id 3) > offset 20 > distance 0 > > Loads-only chain 0x38b68b0 (combined) > max distance 0 > references: > MEM[(real(kind=3D8) *)vectp_a.23_102] (id 0) > offset 0 > distance 0 > MEM[(real(kind=3D8) *)vectp_a.33_33] (id 2) > offset 0 > distance 0 > > Combination chain 0x38b65b0 > max distance 0, may reuse first > equal to 0x38b6730 + 0x38b68b0 in type vector(2) real(kind=3D8) > references: > combination ref > in statement predreastmp.48_10 =3D vect__32.31_78 + vect__28.25_100; > > distance 0 > combination ref > in statement predreastmp.50_17 =3D vect__42.41_138 + vect__38.36_29; > > distance 0 > > It's important to note that distance is equal to zero (happening within a= same loop iteration). > Aforementioned chains correspond to: > > ... > r2: vect__28.25_100 =3D MEM[(real(kind=3D8) *)vectp_a.23_102]; > vectp_a.23_99 =3D vectp_a.23_102 + 16; > vect__28.26_98 =3D MEM[(real(kind=3D8) *)vectp_a.23_99]; > vect__82.27_97 =3D vect__22.22_108; > vect__82.27_96 =3D vect__22.22_107; > vect__79.28_95 =3D vect__82.27_97 + vect__84.17_120; > vect__79.28_94 =3D vect__82.27_96 + vect__84.17_119; > r1: vect__32.31_78 =3D MEM[(real(kind=3D8) *)vectp_a.29_81]; > vectp_a.29_77 =3D vectp_a.29_81 + 16; > vect__32.32_76 =3D MEM[(real(kind=3D8) *)vectp_a.29_77]; > vect__38.35_39 =3D MEM[(real(kind=3D8) *)vectp_a.33_57]; > r2': vectp_a.33_33 =3D vectp_a.33_57 + 16; > vect__38.36_29 =3D MEM[(real(kind=3D8) *)vectp_a.33_33]; > vect__56.37_23 =3D vect__38.35_39; > vect__56.37_15 =3D vect__32.32_76; > vect__42.40_161 =3D MEM[(real(kind=3D8) *)vectp_a.38_163]; > vectp_a.38_141 =3D vectp_a.38_163 + 16; > r1': vect__42.41_138 =3D MEM[(real(kind=3D8) *)vectp_a.38_141]; > vect__54.42_135 =3D vect__42.40_161 + vect__56.37_23; > r1'+r2': predreastmp.50_17 =3D vect__42.41_138 + vect__38.36_29; > predreastmp.51_18 =3D vect__56.37_15; > vect__54.42_134 =3D predreastmp.50_17; > r1+r2: predreastmp.48_10 =3D vect__32.31_78 + vect__28.25_100; > ... > > Problematic construct is that while having load-only chains r1->r1' and r= 2->r2', the combination > is actually r1'+r2'->r1+r2, which cause the troubles. I believe the prope= r fix is to reject such > combinations where combined root stmt does not dominate usages. It's prob= ably corner case as it does > not reuse any values among loop iterations (which is main motivation of t= he pass), it's doing PRE > if I'm right. > > Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. > > Ready to be installed? I'm not sure. If we have such zero distance refs in the IL at the time pcom runs then not handling them will pessimize code-gen for cases where they are part of a larger chain. Esp. I don't like another stmt_dominates_stmt_p call and thus rather not handle length =3D=3D 0 at all... We already seem to go great length in associating stuff when combining stuff thus isn't this maybe an artifact of this association? Maybe we simply need to sort the new chain after combining it so the root stmt comes last? Note that there seems to be only a single length per chain but not all refs in a chain need to have the same distance. This means your fix is likely incomplete? What prevents the situation to arise for distance !=3D 0? Richard. > Martin >