This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: alias.c:nonoverlapping_component_refs_p

    Hum.  I'd have thought variant records would have been implemented via
    nested RECORD and UNION types.  Loosely,

Nested RECORD and QUAL_UNION types, actually.

But that's if there's no record rep clause.  If there is, then the
hierarchy is collapsed and it's represented as a single RECORD_TYPE.
Also, subtypes get collapsed similarly.

    The existance of both RECORD_TYPE and UNION_TYPE implies it.  Otherwise
    why would we need both?

Mostly history, but also because UNION_TYPE means *all* fields overlap and
all start at zero.

    I don't know that only one such stride is going to be that useful.

      struct M {
        int foo;
        int a[3][3][3];
        int bar;
      } m;

    What are you going to fill in for m.a.[i][j][k]?  This is at
    4 + 4*k + 12*j + 36*i.  What's the stride?  4.  How can you 
    distinguish bar from a?  You can't.  Does that tell you anything
    different from 'int a[27]'?  I don't think so.

You're right.  I now don't see what it helps at all, and don't understand
why I thought it did or why nobody else noticed it when I made the posting.
The important thing here is the *bound*, which you can't get from the
offset expression.

    We might ought to re-introduce MEM_DECL.  

I'm concerned about adding too many fields.  Yes, they are shared, but
I still think the are going to be a lot of them.

    Even if we extended my current scheme to handle array references,
    there'll be cases in which we don't discover the decl until cse or
    gcse runs.

I don't follow.  Why isn't this known from the tree?  Are you concerned about
value propagation of pointers here?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]