From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id CE8D53858D28 for ; Fri, 31 Mar 2023 14:55:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CE8D53858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E10F12F4; Fri, 31 Mar 2023 07:55:57 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.110.72]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1963B3F6C4; Fri, 31 Mar 2023 07:55:12 -0700 (PDT) From: Richard Sandiford To: Segher Boessenkool Mail-Followup-To: Segher Boessenkool ,gcc-patches@gcc.gnu.org, richard.sandiford@arm.com Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH v2 2/2] combine: Try harder to form zero_extends [PR106594] References: <20230331121602.GV25951@gate.crashing.org> <20230331143556.GW25951@gate.crashing.org> Date: Fri, 31 Mar 2023 15:55:11 +0100 In-Reply-To: <20230331143556.GW25951@gate.crashing.org> (Segher Boessenkool's message of "Fri, 31 Mar 2023 09:35:57 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-25.5 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,KAM_SHORT,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 List-Id: Segher Boessenkool writes: > On Fri, Mar 31, 2023 at 03:06:41PM +0100, Richard Sandiford wrote: >> This is an alternative presentation of the change that we discussed >> a few weeks ago, and that you already tested: >> >> https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613486.html >> >> The results seem to indicate that the patch had no effect on targets >> other than aarch64. [A good thing, IMO. :-) The purpose of the >> patch is to fix the aarch64 regression in a minimally invasive way.] > > If it is the same (I don't agree at all fwiw) Why don't you agree that it's behaviourally the same? It's really just a refactoring of my earlier patch. > it has no effect on aarch64 either, other than on your single > testcase. So that is a good reason to NAK this patch outside of stage > 1 already. But if it only affected this single testcase, I wouldn't see improvements in 182 kernel objects :-) >> I tried building an aarch64 linux kernel locally with -Os >> -fno-schedule-insns{,2}. > > Completely unrealistic. No one builds anything they care for speed fo > with -Os (and if people care for size, you still get better results > with -O2 + some other tunings), and disabling scheduling is disastrous. As discussed before, the point is to use these results to get an idea of the scope of the change. And if we're using size to measure the scope, it makes sense to align the compiler's goals with that, since we then need to spend less time filtering the results for oddities like different RA leading to different code layout, etc. If we want to measure speed, we should do that. But I don't expect a significant speed impact on the kernel either way (whether the patch is good or bad). Thanks, Richard