[LLVMdev] LICM for function calls

[Hal Finkel]

----- Original Message -----
> From: "Philip Reames" <listmail at philipreames.com>
> To: "Thomas F Raoux" <thomas.f.raoux at intel.com>, llvmdev at cs.uiuc.edu
> Sent: Tuesday, July 14, 2015 11:59:49 PM
> Subject: Re: [LLVMdev] LICM for function calls
> 
> 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. 

I'm fairly certain we already consider declaration attributes to have no control dependencies.

 -Hal

> 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
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory