From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-x1131.google.com (mail-yw1-x1131.google.com [IPv6:2607:f8b0:4864:20::1131]) by sourceware.org (Postfix) with ESMTPS id 2574C3858CDA for ; Mon, 10 Apr 2023 05:09:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2574C3858CDA 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-yw1-x1131.google.com with SMTP id 00721157ae682-54ef6ca60ceso69697007b3.3 for ; Sun, 09 Apr 2023 22:09:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1681103380; x=1683695380; 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=WG8SQk5j5s39uKGdOCh8PqjiwV/cLnEiIHkPJZVCuUM=; b=Pbl7Xh3Du8+LHrXWX34QazUBIwSjSEdAwx5ZJBULPyjFpRDz+UdvlDhHappvXEoHFk WOuVqKo6bcfwLwE77G8TVzDExNanzdidtQ6VPQ+iFhios6US1MhrZ949RD4RWOsUCaMo QCtadwQC6/X6ghv4oMlGaXpyCB0hXS7Nbwlo6W2iVEe22nhrEYUpOp0bTzpxhuAMfQct vzbtBFQsCOEEtti6q79YbFhraouV+/aBk0vQd21lzZqwp2mCDQIAgI+lY/rIUykBn4R3 PO+JJ2ocDKLYA8vdi2h4sdSiAGrFWvCM/cKoLjQ68EVCkkVxik07t/8UZHlKMHtVjd1D 9yMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1681103380; x=1683695380; 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=WG8SQk5j5s39uKGdOCh8PqjiwV/cLnEiIHkPJZVCuUM=; b=eN7okw4Yow0YLCmOpOKA58cxlAzSkoqntkmoUlupVe1xOGo98fVSspX5zXtwe1p79h 9TEMOEfeJ24cGMK0Zb4/GpabctBtIudYDi50YJ8wqCx1sHKVuQBfuydVN/HsfLQoZuZ+ 6FgZSDGlWqX+UZcdqAHOPfpHqI3KdLd+dNLgV4gTXQK04A7byTJK03ZCnKXfu4wILEOt 9CIn5Y0rOq6dDeCJS3OEJ07EyXKoGf8zv4zHcBzymlr0Yjuwww167yXsWUyLiR9f77+x rZZEzVnCO4zIOXWI+IHOIXFsY4gn9h94SW6Yp4/ak88zI2TkEfOGlvdS10BkNRn1oyVJ hGKg== X-Gm-Message-State: AAQBX9efjaBfgkrlghxwjl2jXUgk5dZrNL2V/B3sbPLPD+3/ued0hxsy Vl77YIy3BkxjzK/EDfB9vdRgDMmO2Yg471S7rXU= X-Google-Smtp-Source: AKy350bIxaEHYKAOkf6nmNumta1vmToe/I7AU42nq3MZGd8rVr/+Lzyx1WQF3t+1Cm6mAemN4wT6FWzhdF68zLHu3nU= X-Received: by 2002:a81:ac22:0:b0:54c:bf7:5210 with SMTP id k34-20020a81ac22000000b0054c0bf75210mr3349626ywh.4.1681103380408; Sun, 09 Apr 2023 22:09:40 -0700 (PDT) MIME-Version: 1.0 References: <2876279.e9J7NaK4W3@fomalhaut> <2220543.iZASKD2KPV@fomalhaut> <1b51fda9-b942-bb7f-6406-9ac14a29940c@gmail.com> In-Reply-To: From: Hongtao Liu Date: Mon, 10 Apr 2023 13:15:01 +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=-1.3 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 Mon, Apr 10, 2023 at 1:13=E2=80=AFPM Hongtao Liu wr= ote: > > 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 foll= owing. > > >>> 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= operation > > >> is done on the full word register, in other words that it's in effec= t: > > >> > > >> (subreg:SI (and:SI (reg:SI xxx) (const_int 0x84c)) 0) > > >> > > >> that is equivalent to the initial RTL so correct for WORD_REGISTER_O= PERATIONS. > > > > > > 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 = the > > > 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 thin= g > > is going to happen in the constant case. > > > > THe fact that constants are sign extended from the mode bit is a gcc-is= m > > 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 stil= l > > > 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 call= s > > to nonzero_bits > Li pan and I tried to set SUBREG_PROMOTED_UNSIGNED_P for the I mean SUBREG_PROMOTED_UNSIGNED_SET. > (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 > > > > -- > BR, > Hongtao --=20 BR, Hongtao