llvm dev - Mar 2007 - [LLVMdev] C99 restrict

On Mar 25, 2007, at 2:18 AM, Chris Lattner wrote:
> On Sat, 24 Mar 2007, Christopher Lamb wrote:
>> Has there been any discussion of supporting the 'restrict' C99
>> keyword
>> and C++ extension to boost alias analysis? My impression is that this
>> would require modification of the LLVM IR. I couldn't find any
>> discussion hits using the usual suspects for searches...
>
> 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).

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.

--
Christopher Lamb
christopher.lamb at gmail.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20070325/8dbfadf9/attachment.html>

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.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/

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