[LLVMdev] LICM for function calls

[Philip Reames]

On 07/14/2015 07:45 AM, Raoux, Thomas F wrote:
> Hi,
>
> Right now in LICM (and many other transformations) we always assume it is never safe to speculatively execute a function call.
>
> The following function always return false for all function calls except for few intrinsics:
> bool llvm::isSafeToSpeculativelyExecute(const Value *V,
>                                          const DataLayout *TD) {
> ...
>    case Instruction::Call: {
>     if (const IntrinsicInst *II = dyn_cast<IntrinsicInst>(Inst)) {
> ...
>     }
>      return false; // The called function could have undefined behavior or
>                    // side-effects, even if marked readnone nounwind.
>
> In some cases this could have an important performance impact so I'm looking for a potential way to improve it.
>
> Is there any combination of attributes which would guarantee that a function is safe to speculatively execute a function call? (As far as I can tell there isn't.)
In general, no there isn't.  The challenge is that a function's 
attributes can be control dependent.  For example, you can have a 
function which is "readnone argmemonly nounwind" which writes the entire 
heap if the global "c" is true.  Hoisting a call to such a function 
above "if (!c)" would be problematic.  I think that in practice this is 
mostly an issue with call site attributes, but I believe the same 
conceptual problem applies to attributes on function declarations as 
well.  Changing that might be reasonable, but we'd need to spec it 
carefully.  I think there's room here for improvement, but it'll likely 
be a slow process at first.

One area you might look into is the "guaranteed to execute" notion in 
LICM.  This gives a basis for hoisting a call out of a loop which 
doesn't require speculating it past any relevant control dependence.  
You still have to worry about aliasing for safety, but reasoning about 
the semantics of attributes and faults should be a bit more straight 
forward.
>
> Does anybody have a suggestion on what would be the best way to implement such functionality? Or do you think such optimization is undesirable?
>
> Cheers,
> Thomas
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev