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

[Duncan Sands]

Hi Edwin,

> 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, ...

this comes up with great regularity on the gcc mailing list.  One reason
is that Ada wants 'const' functions to be able to throw exceptions (so
that Ada's pure can be mapped onto 'const'), while C people tend to feel
that 'const' should mean "no side effects", so don't think such functions
should throw exceptions.  I don't think any decision was made.  I think the
solution is to break 'const' up into multiple concepts, i.e. do as you
suggest: have C map 'const' to readnone+nounwind, and have Ada map 'pure'
to readnone.

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

I agree.

> 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)"

See PR965.  The suggested solution is to have yet another
attribute ("willreturn", "finite" or something like that)
that can be used to mark functions that will not infinite loop.
Then have the C front-end add that to 'const' functions, and
have a pass that deduces it using loop info.

> 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.

Right.

> Also what happens with C++'s const member functions?

Nothing special is done for them right now.

> If there are mutable class members they aren't technically readonly, 
> since they have the side-effect of modifying the object.

Yup.

> 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?

You could always cheat and mark it readonly/readnone anyway.  This
might work in some circumstances if no-one can tell that these modifications
are going on.

Ciao,

Duncan.