From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) by sourceware.org (Postfix) with ESMTPS id A4A863858C27 for ; Tue, 4 Jan 2022 07:28:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A4A863858C27 Received: by mail-ed1-x52a.google.com with SMTP id b13so144824358edd.8 for ; Mon, 03 Jan 2022 23:28:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=sfigVbzCJVYgpE3APzccTohhfBVpXAadDV9TMK8z+vw=; b=0PBkyr9S2olEa4MEYP9SCHF/FQtSjPrHUP0SE6YoMCmGLzh+KkORVhLC+khoBqdkJg NHMdZrQ7cWwRnWLg/XImCqb/wMUUjDCY+tsM/7a6XmsbCtNJTvxGdovXtxX+Xgrjo1nV gMKssT0JN6CKjBUcm+XIu5wnKkvJMAZjP/sHr0tgKIwkuQi/9SBUCq36+eSphucZoKtB A6WVcyg2mXJEccKZ8hMsqdPzGNzrtI2wU5EiOj7EmbZsZZtC7wJFu2Ue5XfxeKo05Qbo +PC0QacnhSGfM2LxUYEATvwXvIZuHgGme1JCOHBxh+YGp+41s00EYRc3hsud8tpfFrvs u2kA== X-Gm-Message-State: AOAM533Hq4lHFTvBmhbUE5QYijP1TOUOZMNa83miCP7TUGxctxzL/6wR 9193x0H8+3dlYVuK+a6J3qCEMtQg2esSxHaFhrirFB7r X-Google-Smtp-Source: ABdhPJwbzJ0OlGw12geg0o5CJgahkafDMhdGPPfwTFFkVG1nd6CEW2v3XW9XsFL8GfwQ+JiUxBgKZ8tdW9gbrPmWKdc= X-Received: by 2002:a17:907:7b9a:: with SMTP id ne26mr37753638ejc.240.1641281314695; Mon, 03 Jan 2022 23:28:34 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Tue, 4 Jan 2022 08:28:23 +0100 Message-ID: Subject: Re: Why do these two trees print differently 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=-2.2 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: Tue, 04 Jan 2022 07:28:38 -0000 On Mon, Jan 3, 2022 at 9:16 PM Gary Oblock wrote= : > > Richard, > > I was able figure it out by looking for "MEM" is > tree-pretty-print.c. There is the condition included > at the end of the email (mostly to provoke a chuckle) > necessary for the "p->f" format. If it's not true then > the MEM form is emitted. Yes, there's some loss of information so we don't "pretty" print the MEM. > > What is most interesting from this whole exercise > the question of why am I seeing offsets in > the GIMPLE form? I'm seeing offsets where > the symbolic form using field seems to make > more sense. I'm also seeing accesses with > offsets that are multiples of the structure size. > That kind of idiom seems more appropriate at the > RTL level. That seems to be an unrelated question? Note that GIMPLE is much closer to RTL than you think - GIMPLE is _not_ an AST. You see offsets whenever symbolic (COMPONENT_REF I suppose) is eventually not semantically correct. Richard. > > Thanks, > > Gary > > TREE_CODE (node) =3D=3D MEM_REF > && integer_zerop (TREE_OPERAND (node, 1)) > /* Dump the types of INTEGER_CSTs explicitly, for we can't > infer them and MEM_ATTR caching will share MEM_REFs > with differently-typed op0s. */ > && TREE_CODE (TREE_OPERAND (node, 0)) !=3D INTEGER_CST > /* Released SSA_NAMES have no TREE_TYPE. */ > && TREE_TYPE (TREE_OPERAND (node, 0)) !=3D NULL_TREE > /* Same pointer types, but ignoring POINTER_TYPE vs. > REFERENCE_TYPE. */ > && (TREE_TYPE (TREE_TYPE (TREE_OPERAND (node, 0))) > =3D=3D TREE_TYPE (TREE_TYPE (TREE_OPERAND (node, 1)))) > && (TYPE_MODE (TREE_TYPE (TREE_OPERAND (node, 0))) > =3D=3D TYPE_MODE (TREE_TYPE (TREE_OPERAND (node, 1)))) > && (TYPE_REF_CAN_ALIAS_ALL (TREE_TYPE (TREE_OPERAND (node, 0))) > =3D=3D TYPE_REF_CAN_ALIAS_ALL (TREE_TYPE (TREE_OPERAND (node, 1)))) > /* Same value types ignoring qualifiers. */ > && (TYPE_MAIN_VARIANT (TREE_TYPE (node)) > =3D=3D TYPE_MAIN_VARIANT > (TREE_TYPE (TREE_TYPE (TREE_OPERAND (node, 1))))) > && (!(flags & TDF_ALIAS) > || MR_DEPENDENCE_CLIQUE (node) =3D=3D 0)) > > ________________________________ > From: Richard Biener > Sent: Monday, January 3, 2022 5:49 AM > To: Gary Oblock > Cc: gcc@gcc.gnu.org > Subject: Re: Why do these two trees print differently > > [EXTERNAL EMAIL NOTICE: This email originated from an external sender. Pl= ease be mindful of safe email handling and proprietary information protecti= on practices.] > > > On Wed, Dec 15, 2021 at 7:10 AM Gary Oblock via Gcc wro= te: > > > > This is one of those things that has always puzzled > > me so I thought I break down and finally ask. > > > > There are two ways a memory reference (tree) prints: > > > > MEM[(struct arc_t *)_684].flow > > > > and > > > > _684->flow > > > > Poking under the hood of them, the tree codes and > > operands are identical so what am I missing? > > Try dumping with -gimple, that should show you the difference. > > > > > Thanks, > > > > Gary > > > > > > CONFIDENTIALITY NOTICE: This e-mail message, including any attachments,= is for the sole use of the intended recipient(s) and contains information = that is confidential and proprietary to Ampere Computing or its subsidiarie= s. It is to be used solely for the purpose of furthering the parties' busin= ess relationship. Any unauthorized review, copying, or distribution of this= email (or any attachments thereto) is strictly prohibited. If you are not = the intended recipient, please contact the sender immediately and permanent= ly delete the original and any copies of this email and any attachments the= reto.