From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) by sourceware.org (Postfix) with ESMTPS id 0E4C73858D39 for ; Tue, 28 Mar 2023 13:29:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0E4C73858D39 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-x22b.google.com with SMTP id y35so10044974ljq.4 for ; Tue, 28 Mar 2023 06:29:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680010140; 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=mLFlcJZdcSiqqI54e/3ZfGu8BromlMBPm6VYKE90ph4=; b=b5iM51KWoH3EKQg1AgkOfQUNaNcxBahbAbavHVZNdXoWMsdWhHIqxEoDpxMDkEt5d7 RIsu+15c0F33J835fLRWg7OEnaVQR51ha2yni8bHfW+sOxs13tX7l1gw37vCqBvgKpzz Fk9cRWBuRSrFa3wvzgIvoobYbYgPJOu9ofkim4wH86xfX4E+a41KIM4HBfNtw5kMkRmq QJWuD1fDeMrDinX5oyTOqUpmXdEAPrVimPsEZla16WeHCqspS/Tav+tRpYBWFIOgl9HK Qo7XvbXPDUWzcQ3JHRhHpFNp1j4Eiim6fP7/zX8JogwUt/xDi9e8pb6sZACCmtXzMgFo Op+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680010140; 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=mLFlcJZdcSiqqI54e/3ZfGu8BromlMBPm6VYKE90ph4=; b=KJD132cbPxohyz752JrsI6HypASb+YvEApdToTnrXb3to0Yx4dIZ3q5VxeZhKTgHx7 oAZCm4ai9978W6I1MEIBwIOseGs2ApVsQx0Hwsdf1EnpwVTmL0Mz5A0UCD3+aaKg8vlL zQy+Rx1Y+Qkn7tZWP8384vBP80gBq+0g0z7bw5FCPEkQiJTQGKnqIN5R3DIsov4muctf D59yegMx5/q2VIkZL8bcIUN80mH38givJBwxRRxE8MupOtweIVPmOECwEfwPBpV0fmVj yDExhKfm1VmCciExHiEDpqeu65Bx9nMscpnIZ4ZB4WmIex8RjwylT/bvidXnpe2uXi4J z5Ng== X-Gm-Message-State: AAQBX9czbGmEk4I396XZEcf85cxc01rTYJH32CjYDAYpKoUDK1aLaJ7t QRZao2oM+htFcHw4rDKL15n+SC1qe5qYSfSLgGc= X-Google-Smtp-Source: AKy350bPARAfX6gvDW729BbvN1z00302z232Fe1PBPupNnA3FZ+XdLnI+oTR7ro8D4IZ+npQdOQrMOnY0dpgizOo7fU= X-Received: by 2002:a2e:9792:0:b0:2a3:fc8:711b with SMTP id y18-20020a2e9792000000b002a30fc8711bmr4699008lji.10.1680010140490; Tue, 28 Mar 2023 06:29:00 -0700 (PDT) MIME-Version: 1.0 References: <2e0b9177-f8ce-d55a-d6bb-71eb89a9700d@redhat.com> <86a51d9f-209b-33c4-053f-530210266c4c@redhat.com> In-Reply-To: From: Richard Biener Date: Tue, 28 Mar 2023 15:28:21 +0200 Message-ID: Subject: Re: [PATCH] PR tree-optimization/109274 -Fix compute_operand when op1 == op2 symbolically. To: Andrew MacLeod Cc: Jakub Jelinek , Aldy Hernandez , gcc-patches Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-0.9 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: On Tue, Mar 28, 2023 at 3:19=E2=80=AFPM Andrew MacLeod wrote: > > On 3/24/23 12:36, Jakub Jelinek wrote: > > On Fri, Mar 24, 2023 at 11:52:30AM -0400, Andrew MacLeod wrote: > >> Thanks.. Ive incorporated it into my commit too. > > Note, both my earlier version of the patch and your patch regress: > > FAIL: gcc.dg/tree-ssa/vrp-float-3a.c scan-tree-dump-not evrp "link_erro= r" > > FAIL: gcc.dg/tree-ssa/vrp-float-4a.c scan-tree-dump-not evrp "link_erro= r" > > > > Jakub > > > OK, that was fun. > > I commented in the PR, but the root issue is the way I was trying to > communicate symbolic equivalence on operands to the compute_operand > routines. > > [1, 1 ]=3D a_1 !=3D a_1 > > I was creating a relation record between op1 and op2 indicating they > were equivalent. THis record then gets passed up the gori call chain. > > Reality is that this is not a true equivalence... without looking a the > ranges, we dont know that that is true for general application, and and > furthermore, when applied to something like a1 !=3D a1, you can see the > problem... > > Once I corrected the value_relation record to create records with the > same operand, things went south. > > What we really need is to locally identify when op1 and op2 are the same > symbol, and if there is no other information, pass it locally on that > one statement to the range-op handler. > > Then, once we have processed the statement, we invoke the handler for > that statement to cvreate a record which is passed up the chain. > so for: > > a_1 =3D b_4 + 1.0 > [1, 1] =3D (a_1 !=3D a_1) > > compute_operand_1 starts with no relation record, recognizes > symbolically op1 and op2 are the same, and passes EQ_EXPR locally as the > op1_op2 relation to the handler for NE_EXPR. That handler utilizes the > range of op2 to detemine whether !=3D is true or not based on knowledge > that op1 and op2 are the same value. (for integer always false, for > float, takes a look at NAN) and produces a result. > > Before invoking compute_operand to calculate b_4 with the result of a_1, > handler.op1_op2_relation (lhs); > is invoked to determine if there is a relation generated by the > statement, which will generate (a_1 !=3D a_1), and pass that to compute > operand for use in evaluating b_4. > > Bootstraps on x86_64-pc-linux-gnu with no regressions. OK for trunk? LGTM. Thanks, Richard. > Andrew