Re: Why do these two trees print differently

[Gary Oblock <gary@amperecomputing.com>]

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.

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.

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.guenther@gmail.com>
Sent: Monday, January 3, 2022 5:49 AM
To: Gary Oblock <gary@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.