From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) by sourceware.org (Postfix) with ESMTPS id 392B13857B98 for ; Mon, 18 Sep 2023 09:09:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 392B13857B98 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-x22f.google.com with SMTP id 38308e7fff4ca-2bfbd7d49e7so67409101fa.1 for ; Mon, 18 Sep 2023 02:09:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695028147; x=1695632947; darn=gcc.gnu.org; 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=71Q+Qlk/Bb6UwMguxjv2kkGy4g4Z559DQ9WWb/ntoQs=; b=gg/MBhg6cfHdBLiA6VR8MF/Aatz6TQWWkXAM4Gdyh8B14y1wCquVUzEqSsLORbmWZs CS6Vy/7fwbiUpOGv7GRGo8RVT1b0e/D2Ixi25iEgsgdl4f381NhTNVzegj4YUZaNMMdl OsiIVDaf8s3N7MwEE22D46xGj1/4oaLIVLsJqw8gpocqAzypLrtRQlRr6d7gTCIkTP+p sw4fHJJkABLeYbqB4Te25dXOEYkYU+qJjiwYaW2iRS7MZc+zp4BYdBvJg+UR4mIdth98 aDzUg2OvlH8+AHqM2UjOr1yxTiCApT7R54GA7e5yoReCgtHxYm7ZWVq4k5kiG7Jas/Db mKZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695028147; x=1695632947; 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=71Q+Qlk/Bb6UwMguxjv2kkGy4g4Z559DQ9WWb/ntoQs=; b=Hbim2XbMsYE/5k4rTsDcbJeV30tdvVUHlgE1LBVu/aotVKwP9Bz6xvuTPmXNtnetFG afSd6Fmkz/jbJXqvVYOiUgKdDpgiClgcYeg+urCrsefrSSHbkRPeTv7PloEsguHSeSIK NbG1p61BntvjIEkda0BqN275iVCtw/ajDtiUNzw+t7KkqxYCJq/qhmMm3RBN+lARK9Sf nEkyD6QbhVNnia7o8q7E/LPKGaByYkUtRLX3S70BYtqsTBcIsHAF01lvM14sDpPSu3lj xzJnEb895yctKxCxYut/VLvgdpSZhtoVu7d89oOIgLoS1epgFzO2DIzIu++oi/OaDIkM H5yQ== X-Gm-Message-State: AOJu0YywTUWIWImtbg2gbBacW32FnrJEqvOI5GWful/5oxbplcCIpT0O er3zfxTFI74w8xrtcPu1OFHkFzLF4ABoI1LT6iF+kOo3 X-Google-Smtp-Source: AGHT+IEm2m8sNCeOgN+xsnCxXXmpY3UPm/omOUb/0/OKKJlL0Krh9PEaq78/4Q5u0lsd/gawLlOsXDK1rpelhAZF9Ho= X-Received: by 2002:a2e:87c5:0:b0:2b9:eeaa:1074 with SMTP id v5-20020a2e87c5000000b002b9eeaa1074mr7335312ljj.35.1695028147406; Mon, 18 Sep 2023 02:09:07 -0700 (PDT) MIME-Version: 1.0 References: <20230917014418.1703031-1-apinski@marvell.com> In-Reply-To: <20230917014418.1703031-1-apinski@marvell.com> From: Richard Biener Date: Mon, 18 Sep 2023 11:08:55 +0200 Message-ID: Subject: Re: [PATCH] MATCH: Avoid recusive zero_one_valued_p for conversions To: Andrew Pinski Cc: gcc-patches@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-7.7 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 Sun, Sep 17, 2023 at 3:45=E2=80=AFAM Andrew Pinski via Gcc-patches wrote: > > So when VN finds a name which has a nop conversion, it says > both names are equivalent to each other and the valuaization > function for one will return the other. This normally does not > cause any issues as there is no recusive matches. But after > r14-4038-gb975c0dc3be285, there was one added. So we would > do an infinite recusion on the match and never finish. > This fixes the issue (and adds a comment in match.pd) by > for converts just handle one level instead of being recusive > always. > > OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. OK. > Note the testcase was reduced from tree-ssa-loop-niter.cc and then > changed slightly into C rather than C++ but it still needs exceptions > turned on get the IR that VN would produce this equivalence relationship > going on. Also had to turn off early inline to force put to be inlined la= ter. > > PR tree-optimization/111435 > > gcc/ChangeLog: > > * match.pd (zero_one_valued_p): Don't do recusion > on converts. > > gcc/testsuite/ChangeLog: > > * gcc.c-torture/compile/pr111435-1.c: New test. > --- > gcc/match.pd | 8 +++++++- > .../gcc.c-torture/compile/pr111435-1.c | 18 ++++++++++++++++++ > 2 files changed, 25 insertions(+), 1 deletion(-) > create mode 100644 gcc/testsuite/gcc.c-torture/compile/pr111435-1.c > > diff --git a/gcc/match.pd b/gcc/match.pd > index 97405e6a5c3..887665633d4 100644 > --- a/gcc/match.pd > +++ b/gcc/match.pd > @@ -2188,8 +2188,14 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) > > /* A conversion from an zero_one_valued_p is still a [0,1]. > This is useful when the range of a variable is not known */ > +/* Note this matches can't be recusive because of the way VN handles > + nop conversions being equivalent and then recusive between them. */ > (match zero_one_valued_p > - (convert@0 zero_one_valued_p)) > + (convert@0 @1) > + (if (INTEGRAL_TYPE_P (TREE_TYPE (@1)) > + && (TYPE_UNSIGNED (TREE_TYPE (@1)) > + || TYPE_PRECISION (TREE_TYPE (@1)) > 1) > + && wi::leu_p (tree_nonzero_bits (@1), 1)))) > > /* Transform { 0 or 1 } * { 0 or 1 } into { 0 or 1 } & { 0 or 1 }. */ > (simplify > diff --git a/gcc/testsuite/gcc.c-torture/compile/pr111435-1.c b/gcc/tests= uite/gcc.c-torture/compile/pr111435-1.c > new file mode 100644 > index 00000000000..afa84dd59dd > --- /dev/null > +++ b/gcc/testsuite/gcc.c-torture/compile/pr111435-1.c > @@ -0,0 +1,18 @@ > +/* { dg-options "-fexceptions -fno-early-inlining" } */ > +/* { dg-require-effective-target exceptions } */ > + > +void find_slot_with_hash(const int *); > + > +void put(const int *k, const int *) { > + find_slot_with_hash(k); > +} > +unsigned len(); > +int *address(); > +void h(int header, int **bounds) { > + if (!*bounds) > + return; > + unsigned t =3D *bounds ? len() : 0; > + int queue_index =3D t; > + address()[(unsigned)queue_index] =3D 0; > + put(&header, &queue_index); > +} > -- > 2.31.1 >