From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <hubicka@kam.mff.cuni.cz>
Received: from nikam.ms.mff.cuni.cz (nikam.ms.mff.cuni.cz [195.113.20.16])
 by sourceware.org (Postfix) with ESMTPS id 3C5013858029
 for <gcc-patches@gcc.gnu.org>; Tue,  2 Aug 2022 16:31:44 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3C5013858029
Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202)
 id 52377284ABF; Tue,  2 Aug 2022 18:31:43 +0200 (CEST)
Date: Tue, 2 Aug 2022 18:31:43 +0200
From: Jan Hubicka <hubicka@ucw.cz>
To: Richard Biener <rguenther@suse.de>
Cc: Aldy Hernandez <aldyh@redhat.com>, gcc-patches <gcc-patches@gcc.gnu.org>,
 "MacLeod, Andrew" <amacleod@redhat.com>, Jeff Law <jeffreyalaw@gmail.com>
Subject: Re: [PATCH] Properly honor param_max_fsm_thread_path_insns in
 backwards threader
Message-ID: <YulRbw/lCFK0iSTH@kam.mff.cuni.cz>
References: <04261.122080204410800126@us-mta-529.us.mimecast.lan>
 <CAGm3qMVDA_sZGntOMyYJ=XwkEW2hbFDDYv5h0B6QncbwnRKc9Q@mail.gmail.com>
 <nycvar.YFH.7.77.849.2208021141380.4208@jbgna.fhfr.qr>
 <CAGm3qMX5_Y98V-bAeMmVKi+WsFv=bPg-T69erm27C-6qyRRo=w@mail.gmail.com>
 <nycvar.YFH.7.77.849.2208021156050.4208@jbgna.fhfr.qr>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <nycvar.YFH.7.77.849.2208021156050.4208@jbgna.fhfr.qr>
X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00, DKIM_SIGNED,
 DKIM_VALID, DKIM_VALID_AU, HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_MSPIKE_H3,
 RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE,
 TXREP autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
 server2.sourceware.org
X-BeenThere: gcc-patches@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Aug 2022 16:31:45 -0000

> On Tue, 2 Aug 2022, Aldy Hernandez wrote:
> 
> > On Tue, Aug 2, 2022 at 1:45 PM Richard Biener <rguenther@suse.de> wrote:
> > >
> > > On Tue, 2 Aug 2022, Aldy Hernandez wrote:
> > >
> > > > Unfortunately, this was before my time, so I don't know.
> > > >
> > > > That being said, thanks for tackling these issues that my work
> > > > triggered last release.  Much appreciated.
> > >
> > > Ah.  But it was your r12-324-g69e5544210e3c0 that did
> > >
> > > -  else if (n_insns > 1)
> > > +  else if (!m_speed_p && n_insns > 1)
> > >
> > > causing the breakage on the 12 branch.  That leads to a simpler
> > > fix I guess.  Will re-test and also backport to GCC 12 if successful.
> > 
> > Huh.  It's been a while, but that looks like a typo.  That patch was
> > supposed to be non-behavior changing.
> 
> Exactly my thinking so reverting it shouldn't be a reason for
> detailed questions.  Now, the contains_hot_bb computation is,
> that one was introduced by Honza in r7-6476-g0f0c2cc3a17efa
> together with the comment and a testcase.
> 
> So - Honza, what was the reasoning to look at raw BB counts here
> rather than for example the path entry edge count?
I think the explanation is in the final comment:
  /* Threading is profitable if the path duplicated is hot but also
     in a case we separate cold path from hot path and permit ptimization
     of the hot path later.  Be on the agressive side here. In some estcases,
     as in PR 78407 this leads to noticeable improvements.  */

If you have non-threadable hot path threading out cold paths will make
it easier to be optimized since you have fewer meets in the dataflow.

Honza
> 
> Richard.