[LLVMdev] c const

[Duncan Sands]

Hi Christopher,

> The benefits of a const * __restrict come from two different places.  
> The const part is essentially enforced by the front-end and the  
> restrict part is used to inform the alias analysis (it becomes a  
> noalias parameter attribute). The noalias parameter attribute may be  
> of use to you eventually, but full noalias implementation isn't yet  
> complete. Specifically the case where a function with noalias  
> parameter attributes is inlined does not currently preserve the  
> noalias information.
> 
> > Here's a thread about it:
> >
> > http://lists.cs.uiuc.edu/pipermail/llvmdev/2007-March/thread.html#8291
> 
> You should also take a look at PR 1373, as that is where progress is  
> being tracked. http://llvm.org/bugs/show_bug.cgi?id=1373
> 
> > I don't think anything has been implemented.
> 
> Per the discussion and PR there has been work done to implement the  
> 'noalias' parameter attribute in LLVM, and currently BasicAA will use  
> this attribute to inform alias queries that are made. There has also  
> been work to map __restrict C/C++ pointer and reference parameters  
> onto the noalias parameter attribute. There is still much work to be  
> done to fully implement noalias in LLVM, notably the intrinsic and  
> updates to tolerate/use it, as well as to fully support all uses of  
> the __restrict qualifier in the C/C++ front end.

it looks like noalias might be very useful for Ada: for certain types,
such as array types, the language standard explicitly allows the compiler
to pretend that a formal argument of that type is passed by-copy (= by-value)
for alias analysis purposes, while actually passing it by-reference (= via a pointer).
I'm not sure, but based on Chris's suggested implementation
http://lists.cs.uiuc.edu/pipermail/llvmdev/2007-March/008323.html
it seems that this may map exactly to "noalias".  There is a subtlety
though: the compiler may pretend that a copy was passed in, but it must
correspond to a copy made at the moment of the function call, not later.

In Chris's description
" The semantics of 'noalias' are that they "define a new object" "
it is not specified *when* the new object gets its value; Ada requires
the pretend "new object" to act as if it got its value at the start of
the function body, not later, as if a copy of the real object was made
at that point.

For example, suppose that there are two formal array parameters A and B,
and in the function body A is read then later B is written:
  read from A
...
  write to B
In general it is wrong to re-order the read after the write, since
then the read might get a new value written via B, which would be
inconsistent with A being a copy made at the start of the function
call (instead it would correspond to A being a copy made part way
through the execution of the body, after the write to B).  On the
other hand, if first B is written and later A is read:
  write to B
...
  read from A
then it is legal to re-order the read before the write.

I very much hope that noalias semantics are or can be made to be
consistent with this scheme: it represents an important optimization
for Ada, since the language standard permits it in many significant
cases.

Ciao,

Duncan.