This is the mail archive of the gcc-patches@gcc.gnu.org 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


On Mon, Dec 03, 2001 at 07:54:29AM -0500, Richard Kenner wrote:
> I don't believe it is safe to conclude that if two fields aren't the same,
> they don't overlap.  An example of a case where they do is an Ada subtype
> of a variant record.

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

   type Thread_Attributes (Bound_To_Sproc : Boolean) is
      record
         Thread_Resources : Resource_Vector_T := NO_RESOURCES;
         Thread_Timeslice : Duration          := 0.0;
         case Bound_To_Sproc is
            when False =>
               null;
            when True   =>
               Sproc : sproc_t;
         end case;
      end record;

might be represented as

  typedef struct {
    Resource_Vector_T	Thread_Resources;
    Duration		Thread_Timeslice;
    Boolean		Bound_To_Sproc;
    union {
      struct {
      } f;
      struct {
	sproc_t		Sproc;
      } t;
    } u;
  } Thread_Attributes;

where the compiler automatically transforms

  Thread_Attributes.Sproc

to

  Thread_Attributes.u.t.Sproc

plus whatever sanity checking vs Bound_To_Sproc are required
by the language.

> But that may not be the only case: I see no documentation that such overlap
> is not valid in the tree.

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

But if we decide that such field overlap is legal, we should document
that fact and provide a function that checks to see if two fields do
overlap.  Because I suspect that most folks, myself included, assume
that a RECORD_TYPE is semantically equivalent to a C struct.

> I think the best would be to keep the EXPR as what it is now for better
> print information, but have OFFSET be relative to the underlying decl.
> So we'd know that the actual offset is OFFSET + N * STRIDE for some N.

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

  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.

I think ideally we have a nested construct.  If you want to represent
an array reference with a variable offset, we should just go ahead and
use an ARRAY_REF tree node, and just leave the index part null.  You'd
get your stride from the array type node.

We might ought to re-introduce MEM_DECL.  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.  We should be able
to record that we've discovered that a memory reference belongs to some
global symbol without knowing how that symbol relates to the (partial)
expression that already exists in the mem_attrs.


r~


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