From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=wc/a=4S=gmail.com=richard.guenther@sourceware.org>
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236])
	by sourceware.org (Postfix) with ESMTPS id 890E13858421
	for <gcc-patches@gcc.gnu.org>; Tue, 20 Dec 2022 12:26:21 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 890E13858421
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-x236.google.com with SMTP id x11so12243661ljh.7
        for <gcc-patches@gcc.gnu.org>; Tue, 20 Dec 2022 04:26:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=FGi0EYT3zCeP2mlBg1bmggHNWu3fghJ7Izu4I7O3Lik=;
        b=me6nNXl7/vVHj7JpudijtLxMS93B02jgm4WBzcUaM5b2GclVy6wkPnCnLolEZmB1I8
         6i24lM3R3fKlt7PW8vrpZq9mKRzPzy2k0TIxuq3aLXULcOfEMQ/R2uoSG9wCvZ9EGqs1
         SW3caBh3QzI9/TLYuJh7myOaCN8/SOxGU7kYk4SZptoVv/dpabhpbGrMnbYvp8ZYKc5b
         3koEOMhtcLV96IQ1MT4LdtNeInk0vfh19A9921oqip5B8I4OsBa+mKXiGjuZJQwysoKE
         EP92qcbFH7TH9DtFpqlRMhYPaQ/kllBasDcD9wBjDhN3yC7kls2RO/8o/vxdD8xqzB+N
         BZ+w==
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=FGi0EYT3zCeP2mlBg1bmggHNWu3fghJ7Izu4I7O3Lik=;
        b=JIw+3p48iCoIJ4UYUzzj7N/kUuxg/h0eIvrhzZ6P6whwbJPaEUEwsKhAW5ARP8BeA9
         mPOIQHbk4PzgI2Yk1nQ34/ZArJ7INoEzu9oJ+G9b21Gs/KjaaGRzaLldM6bulRZMesVB
         L8D4wJaGsdkX7dZKfdDgvjnSeMkcSYVJAVkBFbIWiJf10PvAPqRkuYOX3vxtcGDX74mt
         p9ZZNhvL5hH0LPIu4JW7b3QRZVYUwEAqLHlzkn/shd3mxPfct0Q/1tinTSdamjNMBTFD
         qMueg8/dmgagS5C0D0OnMohX4tJf/BxB4UykSy6ClBp6im9uXfZaPmSFykjbRTVsd+3N
         2bSw==
X-Gm-Message-State: ANoB5pnRjd0hRYe8hjCNClvnKixK7oaXlzCjh/hzx6nLTyBXVxVGsB/w
	MIF7IxSJkqa9SvVUnk45h9GMpLwCsLKtRYa88sHl2SWG
X-Google-Smtp-Source: AA0mqf7uinS1UZLCxKg6qQ5li18hJk3dUrO1comi3xujKARsxXFwewvZdLRzojC12ntGlTDQul/In+BelUdcpb7Tv98=
X-Received: by 2002:a05:651c:4d0:b0:27a:b1d:5662 with SMTP id
 e16-20020a05651c04d000b0027a0b1d5662mr7807355lji.356.1671539179922; Tue, 20
 Dec 2022 04:26:19 -0800 (PST)
MIME-Version: 1.0
References: <b50e7ca3-c2c2-c91f-c0c6-c284c7e35c60@redhat.com>
In-Reply-To: <b50e7ca3-c2c2-c91f-c0c6-c284c7e35c60@redhat.com>
From: Richard Biener <richard.guenther@gmail.com>
Date: Tue, 20 Dec 2022 13:26:07 +0100
Message-ID: <CAFiYyc1YxjCNpHAjC6TZ1c5Z1akU-WsBMht2iChVvLpkJEq9dA@mail.gmail.com>
Subject: Re: [PATCH] PR tree-optimization/108139 - Don't use PHI equivalences
 in range-on-entry.
To: Andrew MacLeod <amacleod@redhat.com>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>, "hernandez, aldy" <aldyh@redhat.com>
Content-Type: text/plain; charset="UTF-8"
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: <gcc-patches.gcc.gnu.org>

On Mon, Dec 19, 2022 at 3:57 PM Andrew MacLeod via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> our use of equivalences on range-on-entry calculations cause an issue
> through a PHI node when a back edge is involved.  ie
>     a = VARYING
>     <...>
> bb5
>     b = PHI <UNDEFINED(2), a (5)>
> bb6
>     if (a != 0)
>       goto bb5
>
> since the value of b is undefined on the edge 2->5, we ignore it. The
> range of a on the edge 6->5 is ~[0,0]
> we calculate the range of b to be ~[0,0].   we also provide an
> equivalency between a and b.
>
> Unfortunately the on-entry code looks at equivalencies, and says, "hey,
> a and b are equivalent, so we can use the range of b instead"
>
> So it now thinks a is ~[0,0] and folds away the condition.
>
> The problem is that b can be considered equivalent to a, but the
> converse is not true, because there is a path (2->5) upon which a is not
> equivalent to b.  we have no way to represent a one way equivalence at
> the moment. This patch avoid using that relation in range-on-entry
> calculations.
>
> Perhaps next release I'll add a specific kind of one way equivalence for
> this kind of situation.
>
> Bootstraps on x86_64-pc-linux-gnu with no regressions. OK?

OK.  Note that equivalences across backedges can also result in
values from one cycle iteration to be used in another - a SSA def
in a SSA cycle can have different values.

Richard.

>
> Andrew