This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: alias.c:nonoverlapping_component_refs_p
- From: Richard Henderson <rth at redhat dot com>
- To: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 3 Dec 2001 14:04:45 -0800
- Subject: Re: alias.c:nonoverlapping_component_refs_p
- References: <10112031254.AA08406@vlsi1.ultra.nyu.edu>
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~