From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nikam.ms.mff.cuni.cz (nikam.ms.mff.cuni.cz [195.113.20.16]) by sourceware.org (Postfix) with ESMTPS id 92F6538708DA; Tue, 25 Jun 2024 22:25:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 92F6538708DA Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=ucw.cz Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kam.mff.cuni.cz ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 92F6538708DA Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=195.113.20.16 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1719354328; cv=none; b=D2a9FV3QsVkV/jb0m3lPSE9pq0k4V98hzE0QBxD7HKhBVpEedoTpYkE+Lqz8mY7iA3HFVAtNdbRfzMvLEZPTVwLVya5/SD4YUdMqTYNaCIkPP631+LSaPXPbOMyqWW85pPrmiDaZxxQAaflWvsKcyIYXw4b5JdAoDFfwthar7xE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1719354328; c=relaxed/simple; bh=e/AKdnuMiN9IBy2XcA9avBA+aeE3ZOBxuE3bXg2GpMY=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=UvkH0czFClvMQIjBpKO2V9/Bh3HozoUPABcNfa1Xey4SbeZqAk7AdoCjUYJD9NmXZG2bsN6zxzifLUaQriQZTo8nLxBLNxIDf1vK0UY/0kos0/6RmUDuD7dn7Ol2QeYFSPDk3JyzRGuQdZVkfQAbFq9QwM34+HxIO8FgmiqiU4Y= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 9AFE5287733; Wed, 26 Jun 2024 00:25:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucw.cz; s=gen1; t=1719354324; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=W2XWs6kYBtjIrkDedu/P8lKpJuxIEuLaBNIsK68neac=; b=kJtky/bGlzmM+ZxvjbgQo2Xo39T6KRXLPTUUxUPv8OtWmt5lkFKt9lO2si68+M9QQjGc4b Dgn7Bdm5jI9Ii/+JNQrN6XlYnwX+DWOYZ+0kKvcV2mzwCZ9AEn2h1wpur/AVBAsTIUsNpG ZQg9Guh8EFXCgauWB6KJNI1QTAa6A3Q= Date: Wed, 26 Jun 2024 00:25:24 +0200 From: Jan Hubicka To: "rsandifo at gcc dot gnu.org" Cc: gcc-bugs@gcc.gnu.org Subject: Re: [Bug ipa/114531] Feature proposal for an `-finline-functions-aggressive` compiler option Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,JMQ_SPF_NEUTRAL,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,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 List-Id: > different issue from the one that is raised in the PR. (Unless we think that > -O2 and -O3 should always have the same inlining heuristics henceforward, but > that seems unlikely.) Yes, I think point of -O3 is to let compiler to be more aggressive than what seems desirable for your average distro build defaults (which needs to balance speed and size). > > At the moment, -O3 is essentially -O2 + some -f options + some --param options. > Users who want to pick & chose some of the -f options can do so, and can add > them to stable build systems. Normally, obsolete -f options are turned into > no-ops rather than removed. But users can't pick & choose the --params, and > add them to stable build systems, because we reserve the right to remove > --params without warning. Moreover those --params are slowly chaning their meaning in time. I need to retune inliner when early inlining gets smarter. > > So IMO, we should have an -f option that represents “the inlining parameters > enabled by -O3”, whatever they happen to be for a given release. It's OK if > the set is empty. > > For such a change, it doesn't really matter whether the current --params are > the right ones. It just matters that the --params are the ones that we > currently use. If the --params are changed later, the -f option and -O3 will > automatically stay in sync. I am trying to understand how useful this is. I am basically worried about two things 1) we have other optimization passes that behave differently at -O2 and -O3 (vectorizer, unrolling etc.) and I think we may want to have more. We also have -Os and -O1. So perhaps we want kind of more systmatic solution. We already have -fvect-cost-model that is kind of vectorizer version of the proposed inliner option. 2) inliner is already quite painful to tune. Especially since one really needs to benchmark packages significantly bigger than SPECs which tends to be bit hard to set up and benchmark meaningfully. I usually do at least Firefox and clang where the first is always quite some work to get working well with latest GCC. We SUSE's LNT we also run "C++ behchmarks" which were initially collected as kind of inliner tests with higher abstraction penalty (tramp3d etc.). For many years I benchmarked primarily -O3 and -O3 + profile feedbcak on x86-64 only with ocassional look at -O2 and -Os behaviour which were generally more stable. I also tested other targets (poer and aarch64) but just sporadically, which is not good. After GCC5 I doubled testing to include both lto/non-lto variant. Since GCC10 -O2 started to envolve and needed re-testing too (lto/nonlto). One metric I know I ought to tune is -O2 -flto and FDO which used to be essentially -O3 before the optimization level --params were introduced, but now -O2 + FDO inlining is more conservative which hurts, for example, profiledbootstrapped GCC. So naturally I am bit worried to introduce even more combinations that needs testing and maintenance. If we add user friendly way to tweak this, we also make a promise to keep it sane.