[RFC PATCH] restrict_based_on_field attribute

[Michael Matz]

Hi,

On Mon, 3 Oct 2011, Jakub Jelinek wrote:

> std::vector acts roughly as something having a restrict pointer field,
> i.e. two different std::vector objects will have the pointers pointing to
> a different array, unfortunately unlike e.g. std::valarray we have 3
> different pointers pointing into the array instead of 1, and we can't change
> it without breaking the ABI.  This patch adds an extension, where several
> pointer fields in the same structure can be marked as being a group for
> restrict purposes (so the ISO C99 restrict wording would for them not
> mandate that all accesses are made through pointers based on say _M_start,
> but through pointers based on any of the fields in the group (_M_start,
> _M_finish or _M_end_of_storage in the std::vector case).

Ugh, that's stretching our fragile to unsafe restrict support quite much.  
IMO beyond what we can reasonably be confident to not cause 
miscompilations.  Essentially what you're implicitely assuming is that the 
sources of restrict tags can ultimately be memory, and that this is 
somehow reliable.  It unfortunately isn't.

Keep in mind that the whole current restrict-tag support was designed to 
support fortrans specific needs where we can rely on the compiler 
generating code we most probably (!) won't miscompile later.  Further we 
interpret some of the part where ISO-C says nothing in our favor.  
Together this means that e.g. (intentionally _not_ ISO-C, but sort of 
middle-end speak):

foo (struct s)
{ restrict int *p1 = s.p;
  restrict int *p2 = s.p;
  *p1 = 0; *p2 = 1; return *p1;
}

depends on optimization.  We either generate two restrict tags for p1 and 
p2 (this currently happens when there's no CSE of s.p), or we generate 
only one for p1 and p2 (that's what currently happens with CSE).

Note that both interpretations make sense.  One tag makes sense to make 
the above function work as the user expected (returning 1, not 0).  Two 
tags make sense that this case could be optimized:

foo (struct s)
{ restrict int *p1 = s.p;
  restrict int *p2 = s.p;
  ... accesses of p1[2*i] and p2[2*i+1] intermixed ...
  ... we expect to be able to disambiguate both sets purely because of 
      restrict tags ...
}

We will generate new tags when the source of the load is _not_ restrict 
qualified (conversion that introduce restrict generate new tags).  We will 
generate only one tag when the load _is_ restrict qualified _and_ memory 
CSE has eliminated one of the loads.

In any case, right now the middle end sees memory-loads of restrict 
qualified pointers as source of new restrict tags (and depends on 
optimizations if that isn't what is wanted).  This all works more or less 
for fortran because the array->data pointer usually is loaded only once 
for one array, or at least later memory optimizations come and optimize 
away superflous loads.  For fortran at least we currently _rely_ on such 
memory optimizations to take place in case there are multiple accesses to 
one array (as each of them should better have the same restrict tag).  
Luckily if we disable such optimizations we still can't write 
miscompiled testcases because we would as well disable the transformations 
that make use of the invalid restrict info.  But we certainly should be 
able to create fortran testcases where the restrict tags clearly are 
wrong with disabled memory optimizations.

So, loads generate new tags, and we rely on optimizations that this 
doesn't cause miscompilations via invalid disambiguations, which works 
fine for the restricted set of cases coming from the fortran frontend.

You introduce even more freedom to this mud.  Effectively:

foo (struct s)
{ restrict int *p1 = s.p;
  restrict int *p2 = s.q; // same restrict tag as s.p
}

You're giving the user rope to specify the comment part.  For 
this to not cause miscompilations you absolutely rely on that request to 
not be merely a hint.  The problem is that there's no guarantee that it 
isn't lost:

foo_abstract (restrict *p1, restrict *p2)
{ ... p1 and p2 have different tags ... }
foo { foo_abstract (s.p, s.q); }

or

user does pointer to member games:

foo (struct s)
{ restrict **pp1 = &s.p;
  restrict **pp2 = &s.q;
  ... mem clobber ...
  restrict *p1 = *pp1;
  restrict *p2 = *pp2;  // generate new tag for p2
}

Or our own lowering for MEM_EXPR:

foo (struct s)
{ restrict *p1 = MEM[s, 0];
  restrict *p2 = MEM[s, 4]; // new tag for p2
}

Granted, you're trying to look at the type of s to reconstruct the 
field_decl, but that might be misleading when enough obfuscations are 
present.  For fortran it's impossible to generate any of the breaking 
situations above.

All in all the restrict tag support is extremely fragile when it comes to 
tag source from loads, and deep down even unsafe for generic cases, hence 
I don't think to increase its exposal into that generic direction is a 
good idea.


Ciao,
Michael.