From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) by sourceware.org (Postfix) with ESMTPS id 14B4D3858C50 for ; Thu, 1 Jun 2023 21:03:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 14B4D3858C50 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-pf1-x431.google.com with SMTP id d2e1a72fcca58-64d1a0d640cso1030544b3a.1 for ; Thu, 01 Jun 2023 14:03:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685653383; x=1688245383; 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=gumDM9hxNx/paqz81WmV1RmhNz0mV0JrjzfO5u7mzLY=; b=U204+ul9ilwzTcF0NEq3mbyeOPmKe3LZfG2cjhgXT8rOsz68P0UWtDQzKxprh0kDGV h1gN8Q1d0hNEp4mpv9+CMPSq0QITNmCo2hAUTeqCaaDc29OQO1emFY7Wd0fdstIG+u8u Tqrsj9TG0+CGHJ/XKp7T0ALch/R/hhcAxxFTLjPywxxUsWqauY3TnoPk64KIxN/q35gL 1vUdjma2dkRJcUbpyDXOuCVGYiiMO8bRQqfgDBSb+bEjndlaqvQ1AGsAV2qhv5IJmOT0 cOSh0rnsSw/He0vY5B19X8Rgb3DYso+keYYlSgwxD2zq5uG6lr6Tl5WNRjY4PenLJUYZ zh0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685653383; x=1688245383; 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=gumDM9hxNx/paqz81WmV1RmhNz0mV0JrjzfO5u7mzLY=; b=RA/LVq5h8ZkWSkFCVIDb+By8myY1k3+eEUX+0kuJQtmlNAabGTxdUqhG9Oz7zAqbfY xjkle6fooQMEX70+n7P3yAROMwWF9WCpf7dx00d2vwVU1B1dTF/WB8YU2SLqjKZdpaOt j7bwsIGnFsbz+rQ7SH9eWn7rohDSeTttPaQDHY8+9areGSNnx7t6HPY+AdZZ2usvmoVL e1KM7pYbYRjp6/qmudvuS19T8MCozLDosgCPr1g50clsGrHV3fsS3F0kzw8D590PgJKt zt4Ylyzc0ebo+vDihkCNGFOidpgdhi1Ao42+bM6JKFD+hoQGkI4v9WQ8KJpa5c4tuxN7 9Ikw== X-Gm-Message-State: AC+VfDynY8xs/ec41YImMzOhV3Tmzq3hj9SeMz8tHL0eNouposIsZQiB /M4pgQ3KNdmYXaoexZuT2NW/gbPILoPG/zWSQMQ= X-Google-Smtp-Source: ACHHUZ5Uk00iq3GX1gvFaLJkXaJ4eLV+aYZpb4OQb3yN3zAFVVCxa8KjVdDwmvnxZQ6ZM6WYhh1t5KpxhGmnty4k9ng= X-Received: by 2002:a05:6a20:258a:b0:10f:7abd:fe5e with SMTP id k10-20020a056a20258a00b0010f7abdfe5emr8370021pzd.40.1685653382601; Thu, 01 Jun 2023 14:03:02 -0700 (PDT) MIME-Version: 1.0 References: <20230531043249.2561061-1-apinski@marvell.com> <8ad4dd88-6f6d-3e52-58b8-a703a387b6bc@gmail.com> In-Reply-To: <8ad4dd88-6f6d-3e52-58b8-a703a387b6bc@gmail.com> From: Andrew Pinski Date: Thu, 1 Jun 2023 14:02:49 -0700 Message-ID: Subject: Re: [PATCH] Fix PR 110042: ifcvt regression due to paradoxical subregs To: Jeff Law Cc: Richard Biener , Andrew Pinski , gcc-patches@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.6 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,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 Thu, Jun 1, 2023 at 7:36=E2=80=AFAM Jeff Law wro= te: > > > > On 5/31/23 15:22, Andrew Pinski wrote: > > On Wed, May 31, 2023 at 12:29=E2=80=AFAM Richard Biener via Gcc-patches > > wrote: > >> > >> On Wed, May 31, 2023 at 6:34=E2=80=AFAM Andrew Pinski via Gcc-patches > >> wrote: > >>> > >>> After r14-1014-gc5df248509b489364c573e8, GCC started to emit > >>> directly a zero_extract for `(t1&0x8)!=3D0`. This introduced > >>> a small regression where ifcvt would not do the ifconversion > >>> as there is now a paradoxical subreg in the dest which > >>> was being rejected. Since paradoxical subreg set the whole > >>> register, we can treat it as the same as a reg in the two places. > >>> > >>> OK? Bootstrapped and tested on x86_64-linux-gnu and aarch64-linux-gnu= . > >> > >> OK I guess. I vaguely remember SUBREG_PROMOTED_UNSIGNED_P > >> applies to non-paradoxical subregs but I might be swapping things - ma= ybe > >> you remember better and whether that would cause any issues here? > > > > So I looked into the history of the code in ifcvt.cc, this code was > > added with r6-3071-ge65bf4e814d38c to accept more complex bb > > (https://inbox.sourceware.org/gcc-patches/559FBB13.80009@arm.com/). > > The thread where we start talking about subregs is located with Jeff's > > email starting here: > > https://inbox.sourceware.org/gcc-patches/55BBAFAC.5020608@redhat.com/ . > > > > Jeff, > > I know Richard already approved this patch but could you provide a > > second eye as you were involved reviewing the original code here and I > > want to make sure I understood the code in a a reasonable fashion? > It's been a while. I think my original concerns were with RMW operands > and making sure we tracked all sub-components of such operands correctly. > > That was based on the original version, but that version looks like it > should have been OK after reviewing the details of reg_referenced_p. > It's since moved to DF. > > So the only worry I immediately see is whether or not DF is giving uses > and sets of sub-compenents of a RMW operand or multi-hard register modes. So I looked into the code some more, for bb_valid_for_noce_process_p, we are checking to make sure if a reg that was being set is not used by the comparison (and it works using reg_overlap_mentioned_p that satisfies the multi-hard register mode use case and satisfies the RMW case as we are just checking to make sure it does not do that to the registers of the comparison). For bbs_ok_for_cmove_arith, having the check as paradoxical_subreg_p (rather than a plain SUBREG) satisfies RMW operand case (as it is not a RMW operation) and DF already handles multi-hard register when using FOR_EACH_INSN_DEF/FOR_EACH_INSN_USE (and a paradoxical hard register is an invalid RTL in the first place). I wrote this up more to convince myself this is safe and for future references for others when looking into the code to understand it. Thanks, Andrew > > Jeff