[LLVMdev] Readnone/Readonly Function Attributes and Optimization

[Duncan Sands]

Hi John,

>>> Are functions marked as readnone or readonly in the LLVM IR allowed to
>>> generate output or to exhibit exceptional behavior (e.g., calling
>>> abort(), generating an MMU fault, etc.)?
>> they are allowed to unwind exceptions for example, since in theory this
>> can occur without scrunching externally visible memory (for example unwinding
>> can be done by having functions return an additional boolean value indicating
>> whether an exception was thrown, and have the caller examine this value and do
>> the appropriate branch; such an approach is 100% readnone if the underlying
>> function is). That said, dwarf exception handling can't be used since it
>> writes to global memory all over the place. Anyway, this is why readnone calls
>> with no uses aren't removed unless they are also nounwind.
>>
>> Note that readnone/readonly functions aren't supposed to cause the program to
>> exit, or produce output, i.e. they can do it if they like, but the optimizers
>> will readily remove calls to them even though this changes program behaviour.
>
> Okay, so given several calls with the same input arguments to a function marked
> readnone or readonly but not nounwind, if the return values of all the calls are
> unused, will the optimizers remove *all* the calls or will they remove all but
> one call because there may be at least one call that unwinds the stack? To put
> it another way, do the optimizers ensure that the unwind behavior is preserved
> on all paths after optimization?

they are supposed to, so yes there should be one call left.

Ciao, Duncan.