From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id 89A1E3858C20 for ; Mon, 6 Mar 2023 12:09:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 89A1E3858C20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 326C8lEJ022419; Mon, 6 Mar 2023 06:08:48 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 326C8lEN022418; Mon, 6 Mar 2023 06:08:47 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Mon, 6 Mar 2023 06:08:46 -0600 From: Segher Boessenkool To: Tamar Christina Cc: Jeff Law , Roger Sayle , "'GCC Patches'" , Richard Sandiford Subject: Re: [PATCH] PR rtl-optimization/106594: Preserve zero_extend in combine when cheap. Message-ID: <20230306120846.GM25951@gate.crashing.org> References: <000c01d94ec7$a6921430$f3b63c90$@nextmovesoftware.com> <20230304221749.GK25951@gate.crashing.org> <3b1ed616-5d90-7a66-63b5-bdb5e320eebf@gmail.com> <20230305213340.GL25951@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230305213340.GL25951@gate.crashing.org> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,SPF_HELO_PASS,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: Hi! On Sun, Mar 05, 2023 at 03:33:40PM -0600, Segher Boessenkool wrote: > On Sun, Mar 05, 2023 at 08:43:20PM +0000, Tamar Christina wrote: > Yes, *look* better: I have seen no proof or indication that this would ("looks", I cannot type, sorry) > actually generate better code, not even on just aarch, let alone on the > majority of targets. As I said I have a test running, you may be lucky > even :-) It has to run for about six hours more and after that it needs > analysis still (a few more hours if it isn't obviously always better or > worse), so expect results tomorrow night at the earliest. The results are in: $ perl sizes.pl --percent C[12] C1 C2 alpha 7082243 100.066% arc 4207975 100.015% arm 11518624 100.008% arm64 24514565 100.067% armhf 16661684 100.098% csky 4031841 100.002% i386 0 0 ia64 20354295 100.029% m68k 4394084 100.023% microblaze 6549965 100.014% mips 10684680 100.024% mips64 8171850 100.002% nios2 4356713 100.012% openrisc 5010570 100.003% parisc 8406294 100.002% parisc64 0 0 powerpc 11104901 99.992% powerpc64 24532358 100.057% powerpc64le 21293219 100.062% riscv32 2028474 100.131% riscv64 9515453 100.120% s390 20519612 100.279% sh 0 0 shnommu 1840960 100.012% sparc 5314422 100.004% sparc64 7964129 99.992% x86_64 0 0 xtensa 2925723 100.070% C1 is the original, C2 with your patch. These numbers are the code sizes of a Linux kernel, some defconfig for every arch. This is a good measure of how effective combine was. The patch is a tiny win for sparc64 and classic powerpc32 only, but bad everywhere else. Look at that s390 number! Or riscv, or most of the arm variants (including aarch64). Do you want me to look in detail what causes this regression on some particular target, i.e. why we really still need the expand_compound functionality there? (Btw. "0" means the target did not build. For the x86 targets this is just more -Werror madness that seeped in it seems. For parisc64 and sh it is the choice of config. Will fix.) Segher