From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) by sourceware.org (Postfix) with ESMTPS id 528763858C53 for ; Fri, 25 Aug 2023 07:40:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 528763858C53 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-pg1-x534.google.com with SMTP id 41be03b00d2f7-5657add1073so495767a12.0 for ; Fri, 25 Aug 2023 00:40:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1692949244; x=1693554044; 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=v5+FaI2IbkNbF0driUa2ZCQtFOktOOO1MmHSGrlI2WM=; b=hNelLTMrsTQDgUJ699IHC/kY3AT2TTDLiypY5Xu+jqxV/FdbVVpJ0su9uO5YYDlTjY ZeGDxGRkW5ll6BORIgAK7lur5WK0rNP5xGtX5DrINksXtIZIjHSxw2aBuGFwdiTRYrx1 ULP034Tk3Mb0ANGNGX7konE2zBLVuj5rWNWp0+ajovpuUZm5RwSzu1oJI6NFTqIhxbyk 22rZW+9+uAgGyVuoimlBdPwg/cf6oROlyBon7KyovIJppw27GkPYNsFDqLjWf06xOJ3e EvSE72dxvTSBXYdgj2/QznIl15fONk3+xy9ZTUvqVICr1PpIToHqmlEiUmTx3U6IkJZp P9/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692949244; x=1693554044; 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=v5+FaI2IbkNbF0driUa2ZCQtFOktOOO1MmHSGrlI2WM=; b=ac1nPVzFcsX5ySvoeV8ElXp1KDWe7w/GiZQogdJXPRVuMoWdP6+ebOVeiJ7i8HefTx CdkuXafSeyON86r4rEBXE+wW2H8ZYW0TCIQKesbd270PYf+UuT8cBlaAEFA+qB/GMZGn vOtD+LJaEsPnNXNtnKBmRcIk67W2qRhn67fIo4jJXh8SoPHlE5r3/jzGeu4GZPi7OY54 T5TC3qrS6er4XuAWPwbJKi9OFJC3hzr+9djvHXczgVjib8koKnNQDNx6sW8Kkq4606do RhteOHOilSaioWAshL0YT06xPa10KZ45ly6x5F95U9HxTNIaYylK8uvUfQcsnCXY+CfE Nyww== X-Gm-Message-State: AOJu0Yx/CV70KeJApBfnzsJG4A3a4/+ffxX7OFAad8Zi1vFi5q3wVA1D hs1JWse8Rlb76iX1cQij8CNURH30EUjT0WCRdxQPlmLQSKw= X-Google-Smtp-Source: AGHT+IGEh4U8XCcfoJOs/0vTxAayCgMakXzkOSnEG29B60a/Wcbb1wzeAmvTvSNWLv3Cx1C6hpz8TJOaNT3/AmPlGUc= X-Received: by 2002:a17:90a:6d65:b0:269:4fe8:687 with SMTP id z92-20020a17090a6d6500b002694fe80687mr27300613pjj.19.1692949244092; Fri, 25 Aug 2023 00:40:44 -0700 (PDT) MIME-Version: 1.0 References: <20230824191455.3547513-1-apinski@marvell.com> <20230824191455.3547513-2-apinski@marvell.com> In-Reply-To: From: Andrew Pinski Date: Fri, 25 Aug 2023 00:40:32 -0700 Message-ID: Subject: Re: [PATCH 2/3] MATCH: `a | C -> C` when we know that `a & ~C == 0` To: Richard Biener Cc: Andrew Pinski , gcc-patches@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-7.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,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 Thu, Aug 24, 2023 at 11:37=E2=80=AFPM Richard Biener via Gcc-patches wrote: > > On Thu, Aug 24, 2023 at 9:16=E2=80=AFPM Andrew Pinski via Gcc-patches > wrote: > > > > Even though this is handled by other code inside both VRP and CCP, > > sometimes we want to optimize this outside of VRP and CCP. > > An example is given in PR 106677 where phiopt will happen > > after VRP (which removes a cast for a comparison) and then > > phiopt will optimize the phi to be `a | 1` which can then > > be optimized to `1` due to this patch. > > Also works for xor, no? No, because IOR is a saturation operation while XOR is not. So if you know that x and C are full subsets (nonzero(x) & ~nonzero(C) =3D=3D 0) then A^C is not the constant C but rather just (~A)&C which we already a pattern for that to turn it back in to A^C: /* Simplify (~X & Y) to X ^ Y if we know that (X & ~Y) is 0. */ The only thing you can do for XOR is that if you have `A ^ B` and A and B are known not to share any bits in common (that is nonzero(A) & nonzero(B) =3D=3D 0), you can convert it to `A | B` (that is what simplify-rtx.cc does). Which looks like we don't do on the gimple level. > > > OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. > > OK with or without adding XOR. Ok. Thanks, Andrew > > Richard. > > > Note Similar code already exists in simplify_rtx for the RTL level; > > it was moved from combine to simplify_rtx in r0-72539-gbd1ef757767f6d. > > gcc/ChangeLog: > > > > * match.pd (`a | C -> C`): New pattern. > > --- > > gcc/match.pd | 6 ++++++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/gcc/match.pd b/gcc/match.pd > > index c87a0795667..3bbeceb37b4 100644 > > --- a/gcc/match.pd > > +++ b/gcc/match.pd > > @@ -1456,6 +1456,12 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) > > (if (INTEGRAL_TYPE_P (TREE_TYPE (@0)) > > && wi::bit_and_not (get_nonzero_bits (@0), wi::to_wide (@1)) =3D= =3D 0) > > @0)) > > +/* x | C -> C if we know that x & ~C =3D=3D 0. */ > > +(simplify > > + (bit_ior SSA_NAME@0 INTEGER_CST@1) > > + (if (INTEGRAL_TYPE_P (TREE_TYPE (@0)) > > + && wi::bit_and_not (get_nonzero_bits (@0), wi::to_wide (@1)) =3D= =3D 0) > > + @1)) > > #endif > > > > /* ~(~X - Y) -> X + Y and ~(~X + Y) -> X - Y. */ > > -- > > 2.31.1 > >