[LLVMdev] Safe loads

Peter Cooper peter_cooper at apple.com
Tue Jan 24 13:02:56 PST 2012


On Jan 24, 2012, at 12:39 PM, Chris Lattner wrote:

> 
> On Jan 23, 2012, at 4:22 AM, Roman Leshchinskiy wrote:
> 
>> Hello,
>> 
>> For the Glasgow Haskell Compiler's backend, we would like to let LLVM know
>> that certain loads are safe to execute speculatively and hence to hoist
>> out of loops. At the moment, there doesn't seem to be a mechanism for
>> doing so. There seem to be two ways of implementing this: either allow
>> arbitrary instructions to be marked as safe and have
>> Instruction::isSafeToSpeculativelyExecute return true for those or mark
>> memory regions and extend Value::isDereferenceablePointer to return true
>> for those. Is either of these a good idea? Or is there some other way to
>> do this? FWIW, I quickly prototyped instruction marking using metadata and
>> that seemed to work well enough for us.
> 
> I think that marking the load with metadata would make sense.  Is it safe to load the pointer *anywhere*, or just "ahead of the loop"?  If it is safe to move it anywhere (e.g. because it is a load from constant memory, the optimizer just doesn't know it) then using metadata makes sense.  If it is a region where it is safe, then we'd need to implement something like this:
> http://nondot.org/sabre/LLVMNotes/MemoryUseMarkers.txt
Just for the case of something being from a constant location but the compiler not knowing this, you can attach the "invariant.load" metadata to a load which lets the load be hoisted out of a loop.  This is only currently done on reads from runtime constant globals so the address of the load is known to be valid.

The clang commit to generate it is http://llvm.org/viewvc/llvm-project?view=rev&revision=144318
The llvm commit to use it is http://llvm.org/viewvc/llvm-project?view=rev&revision=144107

Pete
> 
> -Chris
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev




More information about the llvm-dev mailing list