[llvm-commits] [llvm] r70790 - /llvm/trunk/docs/LangRef.html

[Török Edwin]

On 2009-05-03 23:11, Chris Lattner wrote:
> On May 3, 2009, at 1:06 PM, Duncan Sands wrote:
>
>   
>> Hi Chris,
>>
>>     
>>> Remove obsolete wording, the only exception a readnone function can  
>>> throw
>>> is the empty set. :)  Thanks to Fritz for pointing this out.
>>>       
>> what's wrong with a readonly function using unwind?  I think
>> the use of unwind is orthogonal to readonly: it's what the
>> nounwind attribute is for.  Of course a readonly function can't
>> call the C++ throw routine etc, but that's a different issue.
>> If you want readonly to mean: doesn't do anything annoying
>> (no side-effects), then the name should be changed, and the
>> function attributes taught to do loop analysis and not mark
>> a function readonly unless all loops are finite etc.  I think
>> it is better to keep readonly and nounwind separate.
>>     
>
> I can definitely be convinced :), but my understanding is that the  
> compiler currently deletes readonly/readnone calls if they are dead.   
> We could change this to also require them to be nounwind, and change  
> the C front-ends to have pure/const also add nounwind.

I think gcc's pure/const  attributes imply nounwind, though the
documentation doesn't explicitly say so:

`const'
     Many functions do not examine any values except their arguments,
     and have no effects except the return value.  Basically this is
     just slightly more strict class than the `pure' attribute below,
     since function is not allowed to read global memory.


I read "No effect except the return value" = cannot throw exceptions,
does not write to global memory, ...

If this is correct, then nounwind should be added by the C frontend.

Also a function marked as pure/const is not allowed to have infinite
loops either:

"Interesting non-pure functions are functions with infinite loops
     or those depending on volatile memory or other system resource,
     that may change between two consecutive calls (such as `feof' in a
     multithreading environment)"

Of course LLVM can define readonly/readnone to have less strict
requirements, but then the C frontend should add more attributes than
just 'readonly/readnone' for
functions marked pure/const to match gcc's definition if we want
optimizers to take advantage of knowing the strict requirements.

Also what happens with C++'s const member functions?
If there are mutable class members they aren't technically readonly, 
since they have the side-effect of modifying the object.
However most people use this as a 'logical' const, i.e. the object may
be modified, but the new object is equivalent to the old one.
Can this be modeled via an LLVM attribute?

Best regards,
--Edwin