[LLVMdev] setOnlyReadsMemory / setDoesNotAccessMemory

Nyx mcheva at cs.mcgill.ca
Fri Jul 24 12:56:18 PDT 2009


But, which optimization pass will take advantage of those flags?

As for nounwind, that means "can't throw an exception"?

- Maxime


John McCall-2 wrote:
> 
> Nyx wrote:
>> Hello,
>>
>> I'm in a situation where my code is calling many native functions.
>> Sometimes, these calls are simply calls to static "accessor" methods that
>> read a variable in some class object (object pointer as input, member
>> variable value returned as output). I was wondering if using the
>> setOnlyReadsMemory method on the native function objects could help LLVM
>> generate optimized code (because it would then know the function has no
>> side
>> effects), and say, eliminating redundant calls to the same accessor
>> function.
>>
>> Also, I would like to know what setDoesNotAccessMemory means exactly. Is
>> it
>> used to mean that a function accesses no memory (neither read nor write)
>> outside of its stack frame? I'm just puzzled as to the meaning of the
>> flags
>> these two methods set on a function, and whether they are useful or not
>> for
>> LLVM to perform optimizations (and if they are, what optimization pass
>> makes
>> use of them).
>>   
> 
> If you think of there being a "world" of state and recorded 
> side-effects, a readnone
> function completely ignores the world, whereas a readonly function can 
> depend on
> the current state of the world, but can't modify it.  Calls to readnone 
> functions are arbitrarily
> re-orderable (and hence redundant calls can always be joined), but calls 
> to readonly functions
> can't be re-ordered around operations which might modify state.
> 
> The precise meaning of this is kindof up to you.  If you only access 
> immutable memory, that's
> legitimate in a readnone function.  If you allocate new memory, but your 
> program's semantics
> can't distinguish between separate allocations, that's legitimate, too.
> 
> Last time I checked, the optimizers don't consider the possibility of 
> readonly/readnone
> functions unwinding, and hence will happily eliminate calls to 
> readonly/readnone functions,
> even when they aren't marked nounwind.  So if your function can unwind, 
> don't mark it
> readonly/readnone.
> 
> John.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> 

-- 
View this message in context: http://www.nabble.com/setOnlyReadsMemory---setDoesNotAccessMemory-tp24649914p24650944.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.




More information about the llvm-dev mailing list