[LLVMdev] C99 restrict

Christopher Lamb christopher.lamb at gmail.com
Mon Mar 26 00:14:56 PDT 2007



On Mar 25, 2007, at 5:22 PM, Chris Lattner wrote:

> On Sun, 25 Mar 2007, Christopher Lamb wrote:
>>>  So far, there hasn't been a discussion.  IMO, the most important  
>>> form is
>>>  for formal arguments.  That could easily be added thorough the  
>>> use of an
>>>  attribute on the parameter.
>>
>> I assume the idea here is to avoid actually attributing the type  
>> (as was
>> avoided with signed/unsigned integers by differentiating ops).
>
> Yep, exactly.
>
>> What about an approach not unlike how debugging information is  
>> handled? That
>> is have an llvm intrinsic that encodes the known alias free range  
>> for a
>> pointer.
>
> That is another great possibility.  One issue is that I haven't had  
> time
> to study the implications of C99 restrict, so I don't feel  
> qualified to
> propose a concrete solution yet.  Ideally, the mechanism added to LLVM
> would be able to handle restrict as well as fortran argument  
> parameters
> (even if the fortran functions are inlined!), etc.  IOW, we don't  
> want to
> have an feature that just implements C99 restrict, we want a more  
> general
> mechanism which C99 restrict can be implemented in terms of.  It seems
> like an intrinsic would be a good way to do that.

Certainly language independence is a requirement.

I think your point about inlined functions is also valid for restrict  
parameters to functions that have been inlined in C/C++. The aliasing  
guarantees are limited to within that function's scope For an  
intrinsics approach this would require intrinsics which estrict/ 
unrestrict the pointer bounding it's life within the function where  
it is declared restrict. The other approach would be to add  
attributes that mark all uses of the pointers as explicitly alias  
free, which would be much more invasive.

On a related topic, I think that similar types of attributes will be  
needed if LLVM is to support a concurrent memory model. Perhaps these  
could all be rolled into the same package.

Ideally I think it would be nice to be able to start off using  
intrinsics to communicate this kind of information, though it may end  
up as changes to instruction down the line, but I'm not enough of an  
expert to be able to say whether this is a feasible strategy.

--
Christopher Lamb
christopher.lamb at gmail.com





More information about the llvm-dev mailing list