From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) by sourceware.org (Postfix) with ESMTPS id 4CC513894C1E for ; Thu, 22 Jul 2021 12:18:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4CC513894C1E Received: by mail-ej1-x62a.google.com with SMTP id qa36so8045205ejc.10 for ; Thu, 22 Jul 2021 05:18:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=PrCZUUFSubDkFcgPW18wkuJh0+Pd9gdqjIBN7IXyF/8=; b=nMEjMRkHfacX3oR0o05L/x/scbGyg0DC20rD5ooPLiYN8W4bw0JfMl97E1n+qTOwQ/ zYB+yNS9Hfa4zD9HZI2aVMDp0thFxRv4c7jzBOCrEWjA9VkC3Cswjvv/VkKUcDFfFV/f KclPJqgjiNllq+rAaWjeYfa8Kcw76sLtnP7IFBdbgbTcRjlSGPZZQfJ3A9t4gWICmbkx vIgur5sKbAkKgUfBxD4Ps73T/jJVtT4rBGHb7PxjSxuxB/M76IzkuRLSyzSrueqpXwiW Kf37gMD9lQ/aJDM0ZEWqhnL21tMmbE4Zgq+Dx49eOR7PjpNA7gZMDIjiTgcdjA350EmG C3wg== X-Gm-Message-State: AOAM533/18GsIcOs48ikWoORbXg2WX9oiiEaEK6KZxZ0DSKChQ9WOAb6 rUAcAV8qd8rP7u6/g2wXvats4emOkQ56PfsUBwo= X-Google-Smtp-Source: ABdhPJw4CHWXFfeg60nxzRmoNxXG3dTfcgKpEz8uE7L1Wqf3aCqy5qHq/ztO2mFdxW5sYO6RJM20QaAO1ywF/AKQelE= X-Received: by 2002:a17:906:c29a:: with SMTP id r26mr44291041ejz.235.1626956329357; Thu, 22 Jul 2021 05:18:49 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Thu, 22 Jul 2021 14:18:38 +0200 Message-ID: Subject: Re: A value number issue To: Gary Oblock Cc: "gcc@gcc.gnu.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3.0 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.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2021 12:18:51 -0000 On Thu, Jul 22, 2021 at 8:06 AM Gary Oblock via Gcc wrote= : > > I seem to be having a problem with the pre pass. > > When eliminate_dom_walker::eliminate_stmt is called with > the gsi to "dedangled_864 =3D bea_43->tail;" which in turn > calls eliminate_dom_walker::eliminate_avail op of dedangled_864. > This gives VN_INFO (lhs)->valnum of _920. The _920 is not > associated with any SSA variable in the function and I don't > see how it got associated with dedangled_864. This is not > a theoretical issue because it causes an error (the gcc_unreachable > in eliminate_stmt is called.) But you show below the definition of _920 so I don't quite understand your question. You can follow VNs reasoning in the -details dump. > > Here is how _920 (in function main) is used. > > _920 =3D arcnew_916->head; > _921 =3D MEM[(struct node.reorg.reorder *)_920].firstin; > MEM[(struct node.reorg.reorder *)_920].firstin =3D arcnew_916; > > Here is how dedangled_864 is used: > > [local count: 2609125]: > dedangled_863 =3D bea_43->head; > dedangled_864 =3D bea_43->tail; > goto ; [100.00%] > > [local count: 1813121]: > dedangled_865 =3D bea_43->tail; > dedangled_866 =3D bea_43->head; > > [local count: 4422246]: > # dedangled_867 =3D PHI > # dedangled_868 =3D PHI > delta_461 =3D 1; > goto ; [100.00%] > > Note, dedangled_868 is used in an ever widening net of > phis and operations. Also, the other similar statements > > dedangled_863 =3D bea_43->head; > dedangled_865 =3D bea_43->tail; > dedangled_866 =3D bea_43->head; > > don't seem to be malformed. > > I tried using a watchpoint to see what was happening but that turned > out to be not productive in that it was tripping on something > unrelated even if I set it at the start of the pre pass. > > I'm assuming that some of my code is malformed in some > subtle way and I was wondering it anybody had any ideas? > I say subtle because this was all working on a slightly different > version of gcc without the code of some other Ampere optimizations > in the mix (I disabled those optimizations and things still failed.) > > Note, if you guys don't have any ideas the next approach is adding > tons of brute force instrumentation and special purpose sanity > checking to the value numbering routine... please help me avoid that. > > Thanks, > > Gary > > > CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, i= s for the sole use of the intended recipient(s) and contains information th= at is confidential and proprietary to Ampere Computing or its subsidiaries.= It is to be used solely for the purpose of furthering the parties' busines= s relationship. Any unauthorized review, copying, or distribution of this e= mail (or any attachments thereto) is strictly prohibited. If you are not th= e intended recipient, please contact the sender immediately and permanently= delete the original and any copies of this email and any attachments there= to.