From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <matz@suse.de>
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28])
 by sourceware.org (Postfix) with ESMTPS id AE1DC3858C2C
 for <gcc@gcc.gnu.org>; Thu,  9 Sep 2021 12:52:19 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AE1DC3858C2C
Received: from relay2.suse.de (relay2.suse.de [149.44.160.134])
 by smtp-out1.suse.de (Postfix) with ESMTP id B0B4A22054;
 Thu,  9 Sep 2021 12:52:18 +0000 (UTC)
Received: from wotan.suse.de (wotan.suse.de [10.160.0.1])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by relay2.suse.de (Postfix) with ESMTPS id AB7F3A41C9;
 Thu,  9 Sep 2021 12:52:18 +0000 (UTC)
Received: by wotan.suse.de (Postfix, from userid 10510)
 id A1F2A6575; Thu,  9 Sep 2021 12:52:18 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by wotan.suse.de (Postfix) with ESMTP id A02E964BC;
 Thu,  9 Sep 2021 12:52:18 +0000 (UTC)
Date: Thu, 9 Sep 2021 12:52:18 +0000 (UTC)
From: Michael Matz <matz@suse.de>
To: Aldy Hernandez <aldyh@redhat.com>
cc: Richard Biener <richard.guenther@gmail.com>, 
 Jeff Law <jeffreyalaw@gmail.com>, GCC Mailing List <gcc@gcc.gnu.org>, 
 Andrew MacLeod <amacleod@redhat.com>
Subject: Re: More aggressive threading causing loop-interchange-9.c regression
In-Reply-To: <56bd6a6c-0416-7123-c792-521495d69654@redhat.com>
Message-ID: <alpine.LSU.2.20.2109091249420.12583@wotan.suse.de>
References: <09e48b82-bc51-405e-7680-89a5f08e4e8f@redhat.com>
 <alpine.LSU.2.20.2109071406070.12583@wotan.suse.de>
 <cb4191f1-0432-8740-b327-078c2aaff0fa@redhat.com>
 <CAFiYyc3ZBApnN3ks3YExLTLQ8tvEdFV-uuU2MXVVqXFYn+cdRw@mail.gmail.com>
 <d8234eed-6c60-c5fb-8800-5e9c5b932c58@redhat.com>
 <CAFiYyc2KWNEMD31AdYuNJ-dP7ixMsWtTCtokQpcbRrZctTUqzA@mail.gmail.com>
 <6d5695e4-e4eb-14a5-46a6-f425d1514008@redhat.com>
 <alpine.LSU.2.20.2109081627081.12583@wotan.suse.de>
 <alpine.LSU.2.20.2109081736530.12583@wotan.suse.de>
 <56bd6a6c-0416-7123-c792-521495d69654@redhat.com>
User-Agent: Alpine 2.20 (LSU 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00, DKIM_SIGNED,
 DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_NONE, SPF_PASS,
 TXREP autolearn=ham autolearn_force=no version=3.4.4
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on
 server2.sourceware.org
X-BeenThere: gcc@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc mailing list <gcc.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc>,
 <mailto:gcc-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <mailto:gcc-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc>,
 <mailto:gcc-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Sep 2021 12:52:21 -0000

Hello,

On Thu, 9 Sep 2021, Aldy Hernandez wrote:

> The ldist-22 regression is interesting though:
> 
> void foo ()
> {
>   int i;
> 
>   <bb 2> :
>   goto <bb 6>; [INV]
> 
>   <bb 3> :
>   a[i_1] = 0;
>   if (i_1 > 100)
>     goto <bb 4>; [INV]
>   else
>     goto <bb 5>; [INV]
> 
>   <bb 4> :
>   b[i_1] = i_1;
> 
>   <bb 5> :
>   i_8 = i_1 + 1;
> 
>   <bb 6> :
>   # i_1 = PHI <0(2), i_8(5)>
>   if (i_1 <= 1023)
>     goto <bb 3>; [INV]
>   else
>     goto <bb 7>; [INV]

Here there's no simple latch block to start with (the backedge comes 
directly out of the loop exit block).  So my suggested improvement 
(testing if the latch was empty and only then reject the thread), would 
solve this.

> Would it be crazy to suggest that we disable threading through latches 
> altogether,

I think it wouldn't be crazy, but we can do a bit better as suggested 
above (only reject empty latches, and reject it only for the threaders 
coming before the loop optims).


Ciao,
Michael.