From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) by sourceware.org (Postfix) with ESMTPS id 8E6A5385842B for ; Mon, 10 Apr 2023 05:08:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8E6A5385842B 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-yb1-xb29.google.com with SMTP id u13so3676753ybu.5 for ; Sun, 09 Apr 2023 22:08:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1681103282; x=1683695282; 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=xcDqwUXCKswrnaJCi93rpf2TAAFVIU9uhmw3z58IcQ8=; b=WG7DNBGHCHCsnpRBJOOSLVpXgYfo9NML+CCg1GM5VgWJJ3yUyYYKKrQpIPJbXg2Ow2 sNtcFc39YqqN3W+0VGExa/eiDtWgXImBefDUGNL/GD6Q7ndmUd8Wer4lZG4WDbyJ0fPp i6Y9xDPBv/q6d6s18rjMiHehvT/OD6HB/qF3kXn+BDJsFCOMBZwwzvaRWZ8qMV484tsv jQ0i+H6E57SWFF/Nhoke0WuLrTszZPk1TOtB8PNsMtq0szUPCtPm0EOHGUHUJfI85eZp z88JNxT4v4ASJZnJQhdMITRsYp9NyK2vxF1IAyqKEPEHYyrzm1k1xLndZJSr6NVjW42k CtWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1681103282; x=1683695282; 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=xcDqwUXCKswrnaJCi93rpf2TAAFVIU9uhmw3z58IcQ8=; b=lbJt8jQp8TVnLehnP7qOxOVK3u2cV6NXpZYU54XWAvgV0pEgix1E0TP9ujzdLORxWu eGEVR+ky4DEiZoLugVRFMu5XBJqU5KDhC6qQ2YjUOKB7OLPO1Qi7ILRpTwpawROJ8aM5 zmowunnrAJ1D37m+jj9HNEr98Tp2afP85j3NZgPiCdpd+G7GHgFhh5qS2tc6V5wrvCOE z3J1tw+AvV/5Xkm53ALFKRQoDGsxkibmrQgauYJ0er4iefRyDpoyUB/EOlZDSE7yZ5OF +dbQ33HzU6xQZjUBAUxqC0X3Y1hNSL2ofhW6a/S9EgJpQQOejWCwnh1R9rw4Wlp5h/dG fHMQ== X-Gm-Message-State: AAQBX9etIns675Y6oei3mht4h4qbR8T5i3iCxFZHK8lSGE3+VlJ+K4U9 vuEbWt5TFvhX6SW1mB1cUn6zTVV+8Q1fE4MvnM0= X-Google-Smtp-Source: AKy350YRkwGPUcY/AZ8kKPK1I+O6jaQSQu357Pl5ZZFAVbawbp/hr4a64vrne4MQAA8Tez57CxCPpYNH7z20JHhthhA= X-Received: by 2002:a25:df0b:0:b0:b6c:48c3:3c1c with SMTP id w11-20020a25df0b000000b00b6c48c33c1cmr6378827ybg.13.1681103281833; Sun, 09 Apr 2023 22:08:01 -0700 (PDT) MIME-Version: 1.0 References: <2876279.e9J7NaK4W3@fomalhaut> <2220543.iZASKD2KPV@fomalhaut> <1b51fda9-b942-bb7f-6406-9ac14a29940c@gmail.com> In-Reply-To: <1b51fda9-b942-bb7f-6406-9ac14a29940c@gmail.com> From: Hongtao Liu Date: Mon, 10 Apr 2023 13:13:22 +0800 Message-ID: Subject: Re: [PATCH] combine: Fix simplify_comparison AND handling for WORD_REGISTER_OPERATIONS targets [PR109040] To: Jeff Law Cc: Jakub Jelinek , Eric Botcazou , Richard Biener , Richard Sandiford , gcc-patches@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP 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 9, 2023 at 9:15=E2=80=AFAM Jeff Law via Gcc-patches wrote: > > > > On 4/6/23 05:37, Jakub Jelinek wrote: > > On Thu, Apr 06, 2023 at 12:51:20PM +0200, Eric Botcazou wrote: > >>> If we want to fix it in the combiner, I think the fix would be follow= ing. > >>> The optimization is about > >>> (and:SI (subreg:SI (reg:HI xxx) 0) (const_int 0x84c)) > >>> and IMHO we can only optimize it into > >>> (subreg:SI (and:HI (reg:HI xxx) (const_int 0x84c)) 0) > >>> if we know that the upper bits of the REG are zeros. > >> > >> The reasoning is that, for WORD_REGISTER_OPERATIONS, the subword AND o= peration > >> is done on the full word register, in other words that it's in effect: > >> > >> (subreg:SI (and:SI (reg:SI xxx) (const_int 0x84c)) 0) > >> > >> that is equivalent to the initial RTL so correct for WORD_REGISTER_OPE= RATIONS. > > > > If the > > (and:SI (subreg:SI (reg:HI xxx) 0) (const_int 0x84c)) > > to > > (subreg:SI (and:HI (reg:HI xxx) (const_int 0x84c)) 0) > I think it is. In both cases the AND wipes the upper 16 bits. > > > > not really sure what for WORD_REGISTER_OPERATIONS > > means AND with a constant which has the most significant bit set for th= e > > upper bits. > That's a very good question. I'm not sure either. Obviously in the > non-constant case all the bits up to word_mode get used. The same thing > is going to happen in the constant case. > > THe fact that constants are sign extended from the mode bit is a gcc-ism > though and not necessarily indicative of what hardware is going to to. > > > > >> > >> What happens if you disable the step I mentioned (patchlet attached)? > > > > That patch doesn't change anything at all on the testcase, it is still > > miscompiled. > That may be an artifact of later code in combine coming along and > mucking things up in a manner similar. That what I saw after twiddling > simplify_binary_operation_1. See simplify_and_const_int_1 and its calls > to nonzero_bits Li pan and I tried to set SUBREG_PROMOTED_UNSIGNED_P for the (subreg:SI (reg:HI xxx)) after the AND was optimized off. But it looks RA doesn't handle it as expected,not sure it I understand the semantics of SUBREG_PROMOTED_UNSIGNED_P correctly. > > jeff --=20 BR, Hongtao