Re: Implementing "restrict", and other alias questions

[Jeffrey A Law <law at cygnus dot com>]

  In message <199712280112.UAA01060@jfc.>you write:
  > 
  > A while ago I implemented a subset of the C9X "restrict" keyword for egcs.
  > It didn't go into 1.0, and I am now looking at it again and I want opinions.
  > 
  > 0. Does anyone really care about restrict?
I personally don't, but I can see how it would be useful, and if it
does get adopted by C9X I think we should have it.

There was some issue about "restrict" info propagating through inline
functions.  I haven't thought about the problem in detail, but I think
we'll need a solution of some kind.


  > 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).
I don't think it's particularly useful to support it for non-parameters.
Whether or not to accept & ignore/warn for "restrict" use for non-parms
would be based on difficultly, usefullness, standards conformance.

  > 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 don't see it as a serious _technical_ limitation, but I assume that
we'd want to be able to handle C9X conforming code.

  > 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?
Excellent question -- I have absolutely no clue.

Similarly for C++/restrict and Fortran aliasing stuff.  I also agree
that moving stores is not an alias issue, it is a general loop opt
issue.

  > In general the back end needs to be able to ask, is overlap between memory
  > accesses X and Y prohibited by type rules?  I thought about:
Right.  Here's another case where mapping everything into machine
modes loses -- the mapping loses critical information for aliasing.

  > 	A conflict matrix generated by the front end saying whether
  > 	pseudo-registers A and B point to types which can overlap.
  > 
  > 	Recording the types of pseudo-registers and having a callback
  > 	to the front end to detect type based aliasing.
I'd lean towards the second, but I haven't thought about the problem
has much as you.  Can you give us some idea of the pros and cons you
see for each?

  > Note that pseudo-registers can be created by back end optimization passes
  > and it will be important to have proper aliasing information for some of
  > them.
Yup.  I suspect propagation of type info simlar to how we propagate
toplevel object info would do the trick.

jeff