On Mon, Jan 3, 2022 at 9:16 PM Gary Oblock <g...@amperecomputing.com> 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) == 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)) != INTEGER_CST > /* Released SSA_NAMES have no TREE_TYPE. */ > && TREE_TYPE (TREE_OPERAND (node, 0)) != NULL_TREE > /* Same pointer types, but ignoring POINTER_TYPE vs. > REFERENCE_TYPE. */ > && (TREE_TYPE (TREE_TYPE (TREE_OPERAND (node, 0))) > == TREE_TYPE (TREE_TYPE (TREE_OPERAND (node, 1)))) > && (TYPE_MODE (TREE_TYPE (TREE_OPERAND (node, 0))) > == TYPE_MODE (TREE_TYPE (TREE_OPERAND (node, 1)))) > && (TYPE_REF_CAN_ALIAS_ALL (TREE_TYPE (TREE_OPERAND (node, 0))) > == TYPE_REF_CAN_ALIAS_ALL (TREE_TYPE (TREE_OPERAND (node, 1)))) > /* Same value types ignoring qualifiers. */ > && (TYPE_MAIN_VARIANT (TREE_TYPE (node)) > == TYPE_MAIN_VARIANT > (TREE_TYPE (TREE_TYPE (TREE_OPERAND (node, 1))))) > && (!(flags & TDF_ALIAS) > || MR_DEPENDENCE_CLIQUE (node) == 0)) > > ________________________________ > From: Richard Biener <richard.guent...@gmail.com> > Sent: Monday, January 3, 2022 5:49 AM > To: Gary Oblock <g...@amperecomputing.com> > Cc: gcc@gcc.gnu.org <gcc@gcc.gnu.org> > Subject: Re: Why do these two trees print differently > > [EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please > be mindful of safe email handling and proprietary information protection > practices.] > > > On Wed, Dec 15, 2021 at 7:10 AM Gary Oblock via Gcc <gcc@gcc.gnu.org> wrote: > > > > 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 subsidiaries. It > > is to be used solely for the purpose of furthering the parties' business > > 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 > > permanently delete the original and any copies of this email and any > > attachments thereto.
