[LLVMdev] Safe loads

[Roman Leshchinskiy]

On 24/01/2012, at 20:39, 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

For the code that GHC generates, it is safe to load the pointer anywhere in the function that contains the load and those functions don't get inlined. But that's probably too specific to GHC, a general-purpose mechanism would make more sense.

I looked at llvm.lifetime.start before but it has two problems. Firstly, isDeferenceablePointer doesn't seem to take it into account so marking the memory block in question has no effect on the loads. Secondly, the memory block is quite alive when the function is entered and we definitely don't want to replace those loads with undefs. We'd want to be able to mark memory blocks as "alive here" rather than "alive from now on and dead before" and we'd want isDereferenceablePointer to use this information. Alas, this seems somewhat more difficult to implement for someone who has never done any LLVM hacking before.

Roman