* Why do these two trees print differently @ 2021-12-15 6:09 Gary Oblock 2022-01-03 13:49 ` Richard Biener 0 siblings, 1 reply; 6+ messages in thread From: Gary Oblock @ 2021-12-15 6:09 UTC (permalink / raw) To: gcc 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? 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Why do these two trees print differently 2021-12-15 6:09 Why do these two trees print differently Gary Oblock @ 2022-01-03 13:49 ` Richard Biener 2022-01-03 20:16 ` Gary Oblock 0 siblings, 1 reply; 6+ messages in thread From: Richard Biener @ 2022-01-03 13:49 UTC (permalink / raw) To: Gary Oblock; +Cc: gcc 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Why do these two trees print differently 2022-01-03 13:49 ` Richard Biener @ 2022-01-03 20:16 ` Gary Oblock 2022-01-04 7:28 ` Richard Biener 0 siblings, 1 reply; 6+ messages in thread From: Gary Oblock @ 2022-01-03 20:16 UTC (permalink / raw) To: Richard Biener; +Cc: gcc 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Why do these two trees print differently 2022-01-03 20:16 ` Gary Oblock @ 2022-01-04 7:28 ` Richard Biener 2022-01-04 8:59 ` Gary Oblock 0 siblings, 1 reply; 6+ messages in thread From: Richard Biener @ 2022-01-04 7:28 UTC (permalink / raw) To: Gary Oblock; +Cc: gcc On Mon, Jan 3, 2022 at 9:16 PM Gary Oblock <gary@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.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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Why do these two trees print differently 2022-01-04 7:28 ` Richard Biener @ 2022-01-04 8:59 ` Gary Oblock 2022-01-04 14:28 ` Richard Biener 0 siblings, 1 reply; 6+ messages in thread From: Gary Oblock @ 2022-01-04 8:59 UTC (permalink / raw) To: Richard Biener; +Cc: gcc Richard, Well during my exploration of pretty printing I spent a bunch of time looking at mem refs, hence the question. I understand GIMPLE is not an AST. I worked on a in house compiler someplace where the only IR was an AST and it was a really horrible IR so I'm glad GIMPLE isn't an AST. But the tree expressions seem to be chunks of AST (with some other stuff thrown in that could be thought of as node attributes.) Am I wrong to think of them that way? Thanks, Gary ________________________________ From: Richard Biener <richard.guenther@gmail.com> Sent: Monday, January 3, 2022 11:28 PM 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 Mon, Jan 3, 2022 at 9:16 PM Gary Oblock <gary@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.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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Why do these two trees print differently 2022-01-04 8:59 ` Gary Oblock @ 2022-01-04 14:28 ` Richard Biener 0 siblings, 0 replies; 6+ messages in thread From: Richard Biener @ 2022-01-04 14:28 UTC (permalink / raw) To: Gary Oblock; +Cc: gcc On Tue, Jan 4, 2022 at 9:59 AM Gary Oblock <gary@amperecomputing.com> wrote: > > Richard, > > Well during my exploration of pretty printing I spent > a bunch of time looking at mem refs, hence the question. > > I understand GIMPLE is not an AST. I worked on a > in house compiler someplace where the only IR was > an AST and it was a really horrible IR so I'm glad GIMPLE > isn't an AST. But the tree expressions seem to be chunks > of AST (with some other stuff thrown in that could be thought of > as node attributes.) Am I wrong to think of them that way? trees are dual-purpose. It simply shows that GCC evolved over its lifetime ;) Richard. > Thanks, > > Gary > > > ________________________________ > From: Richard Biener <richard.guenther@gmail.com> > Sent: Monday, January 3, 2022 11:28 PM > 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 Mon, Jan 3, 2022 at 9:16 PM Gary Oblock <gary@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.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. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-01-04 14:28 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-12-15 6:09 Why do these two trees print differently Gary Oblock 2022-01-03 13:49 ` Richard Biener 2022-01-03 20:16 ` Gary Oblock 2022-01-04 7:28 ` Richard Biener 2022-01-04 8:59 ` Gary Oblock 2022-01-04 14:28 ` Richard Biener
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).