From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 94132 invoked by alias); 17 Feb 2017 09:07:34 -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 94116 invoked by uid 89); 17 Feb 2017 09:07:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 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=sk:bschmid, U*bschmidt, bschmidt@redhat.com, bschmidtredhatcom X-HELO: mail-ot0-f174.google.com Received: from mail-ot0-f174.google.com (HELO mail-ot0-f174.google.com) (74.125.82.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 17 Feb 2017 09:07:31 +0000 Received: by mail-ot0-f174.google.com with SMTP id 45so27842105otd.2 for ; Fri, 17 Feb 2017 01:07:31 -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; bh=iYDZP10zLmJgsEVhxXMu9RYPK5TM/bwfH+tJ8S7JIFg=; b=lgi5lO5sS7SS1ru4F30m8BSn+gmYVpSQeo1q0pMWGcAbkH34k93MU9haxsr/51Z9FJ DW0wfw1Y5FjwNHmNf1cICRb9oBq1WZlziNqpzGxONGo3Od+Y2AzVepRkpXUoEceEBHPa VQr/ZfEVJCnOTOKjLyogHMPmX+Arfg27S71BkT+wu6tzgpSrSJUsQD3KLiT1+pMKdWhs MvpSL35smVxqstCIg0ZbIkxq6fDneBKjKcJAO+QibZJEImEm/cDskKkPgZSIUO6EIVJP 98cX357CsWcD+9BKLznTR5aNdZ9xvR0OCuJg7zCZ2mJ1iKJ3n3tpU0AfcUcTnjxMq0Fu dGNQ== X-Gm-Message-State: AMke39kLTJgPoWeKokbd6R829IlwNIxwzT3CFeSYXXRT2KK5ONhNyk7swZ0LqT39Uc6PFPaBP5XBUezjzwIAzA== X-Received: by 10.157.45.194 with SMTP id g60mr3346580otb.87.1487322450222; Fri, 17 Feb 2017 01:07:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.40.120 with HTTP; Fri, 17 Feb 2017 01:07:29 -0800 (PST) In-Reply-To: <328a765e-5466-9740-d545-c1a620805ef9@redhat.com> References: <328a765e-5466-9740-d545-c1a620805ef9@redhat.com> From: Richard Biener Date: Fri, 17 Feb 2017 09:11:00 -0000 Message-ID: Subject: Re: fwprop fix for PR79405 To: Bernd Schmidt Cc: GCC Patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2017-02/txt/msg01088.txt.bz2 On Thu, Feb 16, 2017 at 8:41 PM, Bernd Schmidt wrote: > We have two registers being assigned to each other: > > (set (reg 213) (reg 209)) > (set (reg 209) (reg 213)) > > These being the only definitions, we are happy to forward propagate reg 209 > for reg 213 into a third insn, making a new use for reg 209. We are then > happy to forward propagate reg 213 for it in the same insn... ending up in > an infinite loop. > > I don't really see an elegant way to prevent this, so the following just > tries to detect the situation (and more general ones) by brute force. > Bootstrapped and tested on x86_64-linux, verified that the test passes with > a ppc cross, ok? But isn't the issue that we are walking "all uses" (in random order) rather than only processing each stmt once? That is, /* Go through all the uses. df_uses_create will create new ones at the end, and we'll go through them as well. Do not forward propagate addresses into loops until after unrolling. CSE did so because it was able to fix its own mess, but we are not. */ for (i = 0; i < DF_USES_TABLE_SIZE (); i++) { df_ref use = DF_USES_GET (i); if (use) if (DF_REF_TYPE (use) == DF_REF_REG_USE || DF_REF_BB (use)->loop_father == NULL /* The outer most loop is not really a loop. */ || loop_outer (DF_REF_BB (use)->loop_father) == NULL) forward_propagate_into (use); } if that were simply walking all instructions, doing forward_propagat_into on each use on an instruction we'd avoid the cycle (because we stop propagating). Because when propagating DF_USES_TABLE changes. Richard. > > > Bernd >