PATCH to implement `restrict' in C

[Mark Mitchell]

Jeffrey A Law wrote:

> Mostly OK.  I'm not a big fan of the "_t" convention for types, and you will
> not generally find it used in gcc itself (with the exception of dyn-string).

(Which I wrote...)

> Unless we are literally importing this code from elsewhere, we should avoid
> changing the convention for typedefs.

I guess what I don't like is that there is *no* convention for
typedefs.  I'll remove the "_t" bits, though, and try to remember this
in the future.

>
> You code declares xmalloc and xrealloc, it should not do that unless absolute\
ly
> necessary (and it may be, I didn't check this closely).

OK, but then they'll be unprototyped.  The only headers with
xmalloc/xrealloc are rtl.h and tree.h, but neither of those belong in
splay-tree.c.  In fact, splay-tree.[hc] could also go in libiberty.

>
>   > +   else if  (n == (*parent)->right && *parent == (*grandparent)->right)
>   > +     {
>   > +       splay_tree_node_t p = *parent;
> A nit -- too many spaces in the if.

Thanks.

>
> Your patchkit contained alias.c changes twice.  I looked at the first and
> assumed the second was the same :-)

Yes, oops.

>
> I'm not sure we want a -f option to control restrict.  I think we're better o\
ff
> with an option that enables isoc9x features, instead of controlling each one
> separately.

OK.  I'll change the spelling of -frestrict to -fisoc9x, and alter the
documentation accordingly.  If there are other c9x features (like
_Pragma) implemented, they can go under this flag.

>
> Of course we can us __restrict__ for non-iso code.

Right.

>
> Why do we need casts in the call to splay_tree_insert in record_alias_subset?

Sorry, I don't have the code handy.  The answer is probably that the
key/value bits for a splay-tree are supposed to be big enough to hold
any pointer or integer on the host machine.  In alias.c, we don't really
know what representation will be chosen for those types; it could be a
pointer on some machines, but an integer on others, for example.

>
> +      splay_tree_node_t* node;
> :-)  You know the drill here :-)

Dang it; I just can't seem to get my fingers to do that right.

>
> Here's some questions which came up during jfc's original restrict work.  Can
> you comment on any of these questions?
>
> 1. My first implementation, which I wrote based on documentation for Sun's
> compiler, only supports declaring function arguments "restrict".  Would it
> still be useful with this limitation?  Extending restrict to apply to all
> variable declarations would not be too hard, but getting the expected
> semantics might be.  That is, the compiler could be made to accept but
> ignore restrict applied to non-parameter variables (this is legal; I am
> asking if is it good).

Modulo any bugs, my version allows *all* legal uses of `restrict'.  At
present,
the compiler takes advantage of `restrict' for optimization purposes for
function arguments and for variables, but not for members of structures.

>
> 2. C9X restrict is a type qualifier like const or volatile.  My
> implementation made restrict apply to a variable.  So, for example, one can
> not declare
>         typedef int * restrict restrict_pointer_to_int;
> or
>         int * restrict * foo;
> but only
>         int * restrict bar;
> Is this a serious limitation?  It might be hard to change and the changes
> could cause more divergence of the gcc and egcs back end interfaces.

My version allows typedefs involving restrict, and does the proper
type-checking required.  However, writing (via typedefs or otherwise)

  int *restrict *ip;
  int *restrict *jp;

won't do you any good from an optimization standpoint; the compiler
doesn't try to show that `*ip' doesn't alias `*jp' by first showing that
ip != jp.

>
> 3. Are there any C++ constructs with useful aliasing properties?  The
> latest snapshot should know that global non-placement operator new and
> new[] return pointers to unique storage.  Is anything useful known about
> "this" in constructors, destructors, or other member functions?

The only requirement on `this' is that it be non-NULL.  There are no
inherent aliasing properties.

>
> 4. Should C++ support restrict too?  If so, what language specific concerns
> are there?  For example, can member functions be declared "restrict",
> causing the this pointer to be restrict-qualified?

Yes, it should, only that it should be spelled `__restrict__' since
`restrict' is not a reserved word in the present C++ standard.  In fact,
the customer for whom I implemented `restrict' uses it only in C++, and
so I plan to do the work there as soon as we get the present patch into
the tree.

In general, it's very straightforward to extend `restrict' to C++.  The
issue of member function declarations like:

  struct S {
    void f() restrict;
  };

is tricky, though.  If that `restrict' were `const' it would mean that
`this' has type `S const*'.  But, `S restrict*' is illegal; `restrict'
may only refer to pointer (reference) types.  So, using `restrict' in
this context to mean `S* restrict' would be very un-orthogonal.
  
On the other hand, it would be nice to have a way to indicate that
`this' is `restrict'ed, and you can't do it at the definition point
because you don't explicitly declare `this'.  Although I have thought
about this issue, I have not yet decided what to do.  I think that the
right thing is to see what EDG-based C++ compilers that support
`restrict' do, and match it.

>
> And in one of the replies:
>
> > 2. C9X restrict is a type qualifier like const or volatile.  My
> > implementation made restrict apply to a variable.  So, for example,
> > one can not declare typedef int * restrict restrict_pointer_to_int;
> > or int * restrict * foo; but only int * restrict bar; Is this a
> > serious limitation?  It might be hard to change and the changes
> > could cause more divergence of the gcc and egcs back end interfaces.
>
> I think this would be a serious limitation, in the light of C9X
> compliance. When I read the draft right
>
> struct foo{
>   struct foo * restrict next;
>   int value;
> };
>
> Again, the implementation is free to ignore the declaration - it
> should not reject it.

Correct conclusion.  My version accepts the qualifier, but does not make
use of it in terms of calculating aliasing properties.

> Basically I think the patch is mostly OK.  I'd just like some more informatio\
n
> about the issues that were raised regarding the original restrict
> implementation to see if any of them have been dealt with.

I've done my best to address them.  The short answer is that I think the
patch is fully ISO C9x compliant, even where it doesn't take full
advantage of the optimization opportunities provided.  As for C++, I
plan on doing the work, and most of it will be straightforward.  We can
hash out the bit about `restrict' member functions at a later time;
there's no standard to guide us here.

If I make the changes mentioned above, make I check in the patch?


-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com