Re: [PATCH] Make alias_sets_conflict_p less conservative

[Richard Guenther <rguenther at suse dot de>]

On Wed, 5 Mar 2008, Michael Matz wrote:

> Hi,
> 
> On Wed, 5 Mar 2008, Richard Guenther wrote:
> 
> > But - Joseph, do you have any idea if it in theory could be made to work 
> > with char not being alias set zero?  The FE would need to mark every 
> > lvalue of type char with a special flag.
> 
> If that should be possible, it's no different to making 'char' have alias 
> set zero.  Given:
> 
> struct S {char c; int i;};
> struct T {double d;};
> 
> f () {
>   struct S s;
>   s.c = 0;
> }
> 
> Here the lvalue s.c would then have the "special flag" (i suppose the 
> semantic you had in mind for that flag would be "alias everything"), so it 
> would conflict with everything which of course it can't.  It won't 
> conflict with T.d for instance, so we're back to square one.

Hm.  As I said I know of enough code that uses an array of chars as
"memory", even if embedded in a struct.  So,

struct S { int size; char mem[1]; } s;
struct T { double d; } *p;

double f ()
{
  p->d = 1.0;
  s.mem[0] = 0;
  return p->d;
}

here indeed the store to s.mem[0] should conflict with the store and
load from p->d.

But in the case we are trying to fix, the current alias behavior would
make

  s.size = 0;

conflict with the store and load from p->d, which is incorrect.  That
said, somehow we end up asking for the alias set of 's' here instead
of that for 's.size' - or we make that one of 's.size' a different
one from its type.  Which would move the problem we run into in
PR27799 to get_alias_set and away from alias_sets_conflict_p.

Richard.