Thanks! I'll have to see what conditions led to everything working
before and change them to meet reality.
On Thu, 15 Jul 2021 at 10:35, Richard Biener <richard.guent...@gmail.com> wrote:
>
> On Thu, Jul 15, 2021 at 10:22 AM Erick Ochoa via Gcc <gcc@gcc.gnu.org> wrote:
> >
> > Hi,
> >
> > I was sorting SSA trees and DECL_P trees into different buckets. I
> > used DECL_P as a proxy for it being a local/global variable/function
> > (essentially a declaration). It seems that "probabilistically", I'm
> > kinda right. Normally there is no tree that is both an SSA_VAR_P and a
> > DECL_P at the same time, but there appears to be at least one in a
> > couple of large benchmarks.
> >
> > What could lead to a tree being declared both SSA_VAR_P and DECL_P?
>
> /* Nonzero if DECL represents an SSA name or a variable that can possibly
> have an associated SSA name. */
> #define SSA_VAR_P(DECL) \
> (TREE_CODE (DECL) == VAR_DECL \
> || TREE_CODE (DECL) == PARM_DECL \
> || TREE_CODE (DECL) == RESULT_DECL \
> || TREE_CODE (DECL) == SSA_NAME)
>
> there's your answer. SSA_VAR_P and DECL_P are not related in a way
> you think.
>
> > The first instance I've looked at where this happens the variable in
> > the source is a static class member. But are there other cases? And
> > why would it be the case that for smaller benchmarks there seems to be
> > no instance of trees that are both SSA_VAR_P and DECL_P at the same
> > time?
> >
> > I've been interpreting DECL_P as any variable that actually takes up
> > memory. E.g., for every DECL_P variable there will be space allocated
> > on the stack. But SSA_VAR_P does not need space allocated since they
> > are just an abstraction to think about the flow of assignments. For
> > example, we might have the following pseudo-gimple:
> >
> > PARM cond // variable cond is a boolean parameter (also DECL_P)
> > DECL int i. // variable i is a local integer declaration
> > // stack space is reserved for int i
> > if (cond)
> > {
> > i_0 = 0 // i_0 is an SSA variable that corresponds to i
> > }
> > else
> > {
> > i_1 = 1 // same
> > }
> > i_2 = phi(i_0, i_1)
> >
> > In the end i_x will refer to the stack location reserved for i. I
> > think that this is a somewhat naive view of the execution model but it
> > is not until now that I found a counter example.
> >
> > Is the above not the case?
> >
> > As another note, I have not gone through the details on how static
> > class member variables are implemented, so perhaps there are some
> > details there where it would make sense to have a variable be both
> > SSA_VAR_P and DECL_P.
> >
> > Can someone shed some light on this? Thanks!
> >
> > Thanks!
