From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) by sourceware.org (Postfix) with ESMTPS id B49C13858D37 for ; Fri, 28 Apr 2023 07:09:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B49C13858D37 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-lj1-x22c.google.com with SMTP id 38308e7fff4ca-2a8c28158e2so92544821fa.0 for ; Fri, 28 Apr 2023 00:09:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682665780; x=1685257780; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=qIcLo9Iff4cHX8L0nChmWsYGr3chWrKYy7JadTpvMy8=; b=RSh1QbziIBG20kEd82qGgFh26fROmrmDaI6j7Lk08nHXzHNKunaTiGZYeHmLtFC/oR r1MF0I8FUROWR/m2I56dFyq4A7lXIGuCFbU1mmgUA4CsA11KD0YNuSdW8AahR6sRm8mc IiJk4ehhneuxCs5+2wrCoq66JfdPHXuPj84BFGmnoYjOuR6JFf0loj6f/fDj2BX5iiOI 3gbU4rofbecxGDaw64o5GT4Pvz83w+bAuvSPvMeOaqIveGSFtgdsQck7ho3qzitxjI4S iwcwd+bYMle3RRXkUqDxvyVRpwNnE3GM1a9gmFwvnOtokkPwtUXsBxPYy05XCRslNHvM u2dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682665780; x=1685257780; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=qIcLo9Iff4cHX8L0nChmWsYGr3chWrKYy7JadTpvMy8=; b=eZ1iac6YOP/H818QFJLrUkfz4QlRFMxiQpgeyC+jV9nD4vanSQ8TNpCtgHKCdcngGm C2ab8kuEHtK88Rd+aOpuLOiHorak9X4e1snm+y6PqIMX5pbF7a9RKiIrYUXAMv+rpLeK OP9a0vckyYMh7eN4F8uMkvu9lrSnrzQc7i9NBowm0SP9YtyxcwRnf/hSYCZKmp/icpd+ v9c+tEVD8lTIfJWVJ3qAQEVBBJd7z2PVH8sFqaopsMWFQ36BkCNM2dIJWszOQaGw7qpn ZhCmKnRDGB1//l1iuPtfBcxCdlxWKxE17hCW7C4HYefk6hROMOLz75sqsrVAY8rBvf9w 581w== X-Gm-Message-State: AC+VfDxZfISg2yaAkaJJETH0v0JlCXF9p4GEo0dBWrUTOuXXhI5v7kkD /a4XOgyInVHZWnggabxH+ceay/OgEdPnjTvbcOg= X-Google-Smtp-Source: ACHHUZ64so7aK8iG0TKl3U17eNA3aipVaBqe0Hh/CiWqfLeLpby3uJ4g4pVALB5Dk94lrY0+Tp7Z3AP+n1m+or7OZOY= X-Received: by 2002:a2e:7010:0:b0:2a8:b7e9:82ee with SMTP id l16-20020a2e7010000000b002a8b7e982eemr1130717ljc.1.1682665780160; Fri, 28 Apr 2023 00:09:40 -0700 (PDT) MIME-Version: 1.0 References: <00fd01d97620$36a11e20$a3e35a60$@nextmovesoftware.com> In-Reply-To: <00fd01d97620$36a11e20$a3e35a60$@nextmovesoftware.com> From: Richard Biener Date: Fri, 28 Apr 2023 09:08:08 +0200 Message-ID: Subject: Re: [PATCH] PR rtl-optimization/109476: Use ZERO_EXTEND instead of zeroing a SUBREG. To: Roger Sayle Cc: GCC Patches , Segher Boessenkool Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Sun, Apr 23, 2023 at 10:14=E2=80=AFPM Roger Sayle wrote: > > > This patch fixes PR rtl-optimization/109476, which is a code quality > regression affecting AVR. The cause is that the lower-subreg pass is > sometimes overly aggressive, lowering the LSHIFTRT below: > > (insn 7 4 8 2 (set (reg:HI 51) > (lshiftrt:HI (reg/v:HI 49 [ b ]) > (const_int 8 [0x8]))) "t.ii":4:36 557 {lshrhi3} > (nil)) > > into a pair of QImode SUBREG assignments: > > (insn 19 4 20 2 (set (subreg:QI (reg:HI 51) 0) > (reg:QI 54 [ b+1 ])) "t.ii":4:36 86 {movqi_insn_split} > (nil)) > (insn 20 19 8 2 (set (subreg:QI (reg:HI 51) 1) > (const_int 0 [0])) "t.ii":4:36 86 {movqi_insn_split} > (nil)) > > but this idiom, SETs of SUBREGs, interferes with combine's ability > to associate/fuse instructions. The solution, on targets that > have a suitable ZERO_EXTEND (i.e. where the lower-subreg pass > wouldn't itself split a ZERO_EXTEND, so "splitting_zext" is false), > is to split/lower LSHIFTRT to a ZERO_EXTEND. > > To answer Richard's question in comment #10 of the bugzilla PR, > the function resolve_shift_zext is called with one of four RTX > codes, ASHIFTRT, LSHIFTRT, ZERO_EXTEND and ASHIFT, but only with > LSHIFTRT can the setting of low_part and high_part SUBREGs be > replaced by a ZERO_EXTEND. For ASHIFTRT, we require a sign > extension, so don't set the high_part to zero; if we're splitting > a ZERO_EXTEND then it doesn't make sense to replace it with a > ZERO_EXTEND, and for ASHIFT we've played games to swap the > high_part and low_part SUBREGs, so that we assign the low_part > to zero (for double word shifts by greater than word size bits). > > This patch has been tested on x86_64-pc-linux-gnu with a make > bootstrap and make -k check, both 64-bit and 32-bit, with no > new regressions. Many thanks to Jeff Law for testing this patch > on his build farm, which spotted an issue on xstormy16, which > should now be fixed by (either of) my recent xstormy16 patches. > Ok for mainline? OK. Thanks, Richard. > > 2023-04-23 Roger Sayle > > gcc/ChangeLog > PR rtl-optimization/109476 > * lower-subreg.cc: Include explow.h for force_reg. > (find_decomposable_shift_zext): Pass an additional SPEED_P argume= nt. > If decomposing a suitable LSHIFTRT and we're not splitting > ZERO_EXTEND (based on the current SPEED_P), then use a ZERO_EXTEN= D > instead of setting a high part SUBREG to zero, which helps combin= e. > (decompose_multiword_subregs): Update call to resolve_shift_zext. > > gcc/testsuite/ChangeLog > PR rtl-optimization/109476 > * gcc.target/avr/mmcu/pr109476.c: New test case. > > > Thanks in advance, > Roger > -- >