From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <aldyh@redhat.com>
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124])
	by sourceware.org (Postfix) with ESMTPS id EF8AA3856941
	for <gcc-patches@gcc.gnu.org>; Thu, 20 Oct 2022 22:44:44 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EF8AA3856941
Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1666305884;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references;
	bh=I4SaDpi+y4ruWY5Gla3X8CSz44yl7N0Oq7unLvHl1fo=;
	b=iMzuhnz/BYjuzLUx5zLFAHBsIqbbJNAVz6nF+YGtvMpT6Omhrp+oEebj8R7c3IB9gTAUAA
	sMePSrRK0irmReprqI+CufqLpSquVBw4FvCrqATHSLV7bGkQIH5zxxYjBKSe3VmObiMZvl
	BrAaSVhhTjoXppE6Zd27aMcDv+N67LU=
Received: from mail-yb1-f199.google.com (mail-yb1-f199.google.com
 [209.85.219.199]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id
 us-mta-175-8614hyPBNPujLY3LbUXLXQ-1; Thu, 20 Oct 2022 18:44:42 -0400
X-MC-Unique: 8614hyPBNPujLY3LbUXLXQ-1
Received: by mail-yb1-f199.google.com with SMTP id e8-20020a5b0cc8000000b006bca0fa3ab6so1147329ybr.0
        for <gcc-patches@gcc.gnu.org>; Thu, 20 Oct 2022 15:44:42 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=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=I4SaDpi+y4ruWY5Gla3X8CSz44yl7N0Oq7unLvHl1fo=;
        b=sSvr13bC6PzDrLNWOlHTWCzVjqKtWtwNUci/ZbNwv9oyMoBgKCMk2ZgytrBN0mZ7x+
         RCIIOvM2uqvx2aP6PkA1q4HRE6qUWivrz+anjHGhAjWEmiE3zLKG7GD+NETYSd/fps7L
         ykM9ur7UUOtxUnMBqvAAZqjMOEzr0CP+6ka0gCfwaC7Zy8CZK6xbwOptQhCKv5ukBcig
         x4n0Ak7htc7fIYMoE9fDWkQ/y7PWp3PaH7igE4wJab6wgHNOCH6oPufUA3sWyOwXqUAs
         a/ccom7UMKU9PUei8aJaoRiR5YSuGR+bJf5avvlGga2tttPeVBBZNiumuW9fqalFxUwl
         k2xw==
X-Gm-Message-State: ACrzQf3O0ZZ+7Fh6OoJ0IuuGFn0EUy2OFhZ8a4n9xTb5BLRqodwlQvxD
	NEG0dm6tGCtk6ayvTrJHrCnYSzewtOjzW7wTrjMOFZzUiouavJ5EwUMfqsr1ba9z7+lCGpazOnG
	zR7r3+JzNm241xxlYhygOAGZ15ZNF+pVvvg==
X-Received: by 2002:a25:2d56:0:b0:6c9:a6f7:6eda with SMTP id s22-20020a252d56000000b006c9a6f76edamr9451889ybe.80.1666305881986;
        Thu, 20 Oct 2022 15:44:41 -0700 (PDT)
X-Google-Smtp-Source: AMsMyM7NASwSNkDvd2a32ewYsw+tKvc1PXj9nFZFbME3qIFgpbm+KkOKIwoEyFletcjm8y1JCjbm46vQGnGyhwLHJr8=
X-Received: by 2002:a25:2d56:0:b0:6c9:a6f7:6eda with SMTP id
 s22-20020a252d56000000b006c9a6f76edamr9451876ybe.80.1666305881782; Thu, 20
 Oct 2022 15:44:41 -0700 (PDT)
MIME-Version: 1.0
References: <20221011083137.336470-1-aldyh@redhat.com> <878rlej3o6.fsf@euler.schwinge.homeip.net>
 <CAGm3qMWQLevXbN+6W81vZ+BMd-upW6LBouM+ENn8Mpe9X7+ZNg@mail.gmail.com>
 <87o7uafqyf.fsf@dem-tschwing-1.ger.mentorg.com> <CAGm3qMV_346n1QFT1Ors6BdNZw26gOF3xMq7T170SgkjDG+TkQ@mail.gmail.com>
 <87y1taencs.fsf@dem-tschwing-1.ger.mentorg.com> <CAGm3qMVY0dyzP=mfHmbLg=WDCByOvx1PSdjJ2EuTk32pKy+OAw@mail.gmail.com>
 <87mt9qe1wf.fsf@dem-tschwing-1.ger.mentorg.com>
In-Reply-To: <87mt9qe1wf.fsf@dem-tschwing-1.ger.mentorg.com>
From: Aldy Hernandez <aldyh@redhat.com>
Date: Fri, 21 Oct 2022 00:44:30 +0200
Message-ID: <CAGm3qMV5_7hEED6_NKNAFaiE5dFXapsrRGEd_MAqNiSsF15nmw@mail.gmail.com>
Subject: Re: Add 'gcc.dg/tree-ssa/pr107195-3.c' [PR107195] (was: Add
 'c-c++-common/torture/pr107195-1.c' [PR107195] (was: [COMMITTED] [PR107195]
 Set range to zero when nonzero mask is 0.))
To: Thomas Schwinge <thomas@codesourcery.com>
Cc: gcc-patches@gcc.gnu.org, "MacLeod, Andrew" <amacleod@redhat.com>
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,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: <gcc-patches.gcc.gnu.org>

On Thu, Oct 20, 2022 at 9:22 PM Thomas Schwinge <thomas@codesourcery.com> wrote:
>
> Hi!
>
> On 2022-10-20T14:23:33+0200, Aldy Hernandez <aldyh@redhat.com> wrote:
> >> I understand 'r & 3' to be logically equivalent to '(r & 2) && (r & 1)',
> >> right?
> >
> > For r == 2, r & 3 == 2, whereas (r & 2) && (r & 1) == 0, so no?
>
> Thanks, and now please let me crawl back under my stone, embarassing...
> That'd rather be '(r & 2) || (r & 1)'.

No worries.  If there was a tally of how many times a GCC hacker has
to crawl under a stone, I'd have the record ;-).

>
> Well, with that now clarified, how about the again updated
> "Add 'gcc.dg/tree-ssa/pr107195-3.c' [PR107195]" attached?

I see 7 different tests in this patch.  Did the 6 that pass, fail
before my patch for PR107195 and are now working?   Cause unless
that's the case, they shouldn't be in a test named pr107195-3.c, but
somewhere else.

I see there's one XFAILed test in your patch, and this certainly
doesn't look like something that has anything to do with the patch I
submitted.  Perhaps you could open a PR with an enhancement request
for this one?

That being said...

/* { dg-additional-options -O1 } */
extern int
__attribute__((const))
foo4b (int);

int f4b (unsigned int r)
{
  if (foo4b (r))
    r *= 8U;

  if ((r / 2U) & 2U)
    r += foo4b (r);

  return r;
}
/* { dg-final { scan-tree-dump-times {gimple_call <foo4b,} 1 dom3 {
xfail *-*-* } } } */

At -O2, this is something PRE is doing,  so GCC already handles this.
However, you are suggesting this isn't handled at -O1 and should be??
None of the VRPs run at -O1 so ranger-vrp won't even get a chance.
However, DOM runs at -O1 and it uses ranger to do simple copy
propagation and some jump threading...so technically we could do
something...

DOM should be able to thread from the r *= 8U to the return because
the nonzero mask (known zeros) after the multiplication is 0xfffffff8,
which it could use to solve the second conditional as false.  This
would leave us with:

if (foo4b (r))
  {
    r *= 8U;
   return r;
  }
else
  {
     if ((r / 2U) & 2U)
       r += foo4b (r);
  }

...which exposes the fact that the second call to foo4b() has the same
"r" as the first one, so it could be folded.  I don't know whose job
it is to notice that two const calls have the same arguments, but ISTM
that if we thread the above correctly, someone should be able to clean
this up.  No clue whether this happens at -O1.

However... we're not threading this.  It looks like we're not keeping
track of nonzero bits (known zeros) through the division.  The
multiplication gives us 0xfffffff8 and we should be able to divide
that by 2 and get 0x7ffffffc which solves the second conditional to 0.

So...maybe DOM+ranger could set things up for another pass to clean this up?

Either way, you could open an enhancement request, if anything to keep
the nonzero mask up to date through the division.

Aldy