From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=PhnD=C5=kam.mff.cuni.cz=hubicka@sourceware.org>
Received: from nikam.ms.mff.cuni.cz (nikam.ms.mff.cuni.cz [195.113.20.16])
	by sourceware.org (Postfix) with ESMTPS id E63713858C62
	for <gcc-patches@gcc.gnu.org>; Tue, 11 Jul 2023 12:40:29 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E63713858C62
Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=ucw.cz
Authentication-Results: sourceware.org; spf=none smtp.mailfrom=kam.mff.cuni.cz
Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202)
	id 9E62E281D37; Tue, 11 Jul 2023 14:40:28 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucw.cz; s=gen1;
	t=1689079228;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references;
	bh=5qDGw7KM7VwqyX7qkPWrW9kaJ8AR4O5rMTXufh9I37s=;
	b=jU2nlC+NOjpPCu8fo3o229T2AZsOzXa7YBcPWXP3NjnK8DA0vypGX0RK3JTY6ha/ofVcNA
	w1rD/OUxdKO9Xuija0dGA/vgKyjzjFBkqWkM9kkVwu2WvFGRBpKgVSLJm3qsk1d8vMNxaz
	+qN1eIAmx8m9Ujl4baHepLQhbVTmmJ8=
Date: Tue, 11 Jul 2023 14:40:28 +0200
From: Jan Hubicka <hubicka@ucw.cz>
To: Richard Biener <rguenther@suse.de>
Cc: Tamar Christina <tamar.christina@arm.com>, gcc-patches@gcc.gnu.org,
	nd@arm.com, jlaw@ventanamicro.com
Subject: Re: [PATCH 4/19]middle-end: Fix scale_loop_frequencies segfault on
 multiple-exits
Message-ID: <ZK1NvAezuu7hShmZ@kam.mff.cuni.cz>
References: <nycvar.YFH.7.77.849.2307041137250.4723@jbgna.fhfr.qr>
 <ZKQzSJcEUL5SH0KG@kam.mff.cuni.cz>
 <ZKbQ7DE2cxU1hA96@kam.mff.cuni.cz>
 <nycvar.YFH.7.77.849.2307070557080.4723@jbgna.fhfr.qr>
 <ZKgC/9WHxvuD3qdA@kam.mff.cuni.cz>
 <nycvar.YFH.7.77.849.2307100654500.4723@jbgna.fhfr.qr>
 <ZKvOJZD83UUXTSnE@kam.mff.cuni.cz>
 <nycvar.YFH.7.77.849.2307100925260.4723@jbgna.fhfr.qr>
 <ZK0gsKhkcKUMlmtU@kam.mff.cuni.cz>
 <nycvar.YFH.7.77.849.2307111029430.4723@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.2307111029430.4723@jbgna.fhfr.qr>
X-Spam-Status: No, score=-5.2 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,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org
List-Id: <gcc-patches.gcc.gnu.org>

> > By now we did CCP and FRE so we likely optimized out most of constant
> > conditionals exposed by inline.
> 
> So maybe we should simply delay re-propagation of the profile?  I
> think cunrolli doesn't so much care about the profile - cunrolli
> is (was) about abstraction removal.  Jump threading should be
> the first pass to care.

That is what I was thinking too.  After inlining the profile counts may
be in quite bad shape. If you inline together loop like in exchange that
has large loop nest, we will definitely end up capping counts to avoid
overflow.

cunrolli does:

 ret = tree_unroll_loops_completely (optimize >= 3, false);

which sets may_increase_size to true for -O3 and then

 may_increase_size && optimize_loop_nest_for_speed_p (loop)

which seems reasonable guard and it may get random answers on capped
profile.  It is not big deal to try propagating before cunrolli and then
again before threading and see how much potential this idea has.
I guess I should also double check that the other passes are indeed
safe, but I think it is quite obvoius they should be.

Honza
> 
> Richard.