Re: Incorrect bitfield aliasing with Tree SSA

[Laurent GUERBY <laurent at guerby dot net>]

On Sun, 2007-06-17 at 17:02 -0400, Daniel Berlin wrote:
> On 6/17/07, Laurent GUERBY <laurent@guerby.net> wrote:
> > In Ada if you have a struct type, components of the struct
> > that do not have the explicit keyword "aliased" cannot
> > have their adress taken. Example:
> >
> > type T1 is record
> >    J : Integer;
> > end record;
> >
> > X1 : T1;
> >
> > => then X1.J "address" cannot be taken in legal Ada, so no integer
> > pointer can ever point to it.
> 
> However, can a pointer to X1, stored into, affect J?

In the particular case above there cannot be a pointer to X1 in the
program. But if you have:

X1 : aliased T1;

Then yes a pointer P1 to X1 can exist, and then P1.all.J is legal.

There are some record types which are automatically aliased, for
example object oriented stuff ("tagged" types in Ada) but most simple
records are non aliased in Ada "normal" code that's why it could
pessimize code to assume all components are aliased.

If aliased variable/aliased type Y1 has a T1 component then of course
you can modify J through a pointer to the container.

> If so, field J's alias set must be marked as a subset of X1's alias
> set, or we will get the info wrong.  We currently do *not* mark field
> J's alias set as a subset of X1's, because J is DECL_NONADDRESSABLE_P.
> 
> (This is in fact, the problem we are hitting here in C.  We do *not*
> record  the alias as a subset, which in effect, claims a pointer to
> the structure can never touch the field, which is wrong.
> The correct place for such optimization is to do it per-memory
> reference, not to screw up the type based info)

I can't comment here :).

Laurent