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.)
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
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
----- 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
----- Original Message -----> From: "Thomas F Raoux" <thomas.f.raoux at intel.com> > To: llvmdev at cs.uiuc.edu > Sent: Tuesday, July 14, 2015 9:45:20 AM > Subject: [LLVMdev] LICM for function calls > > 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.) > > Does anybody have a suggestion on what would be the best way to > implement such functionality? Or do you think such optimization is > undesirable?I think we'd need some kind of 'safe_to_speculate' attribute on the function. Regarding the optimization, under what circumstances would you want to speculate a function? I can imagine doing this only if I knew the function would be lowered in the backend to some simple set of instructions. -Hal> > Cheers, > Thomas > > _______________________________________________ > 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
The common case is wanting LICM to hoist a loop-invariant function call into the pre-header of a loop where the trip count is unknown - and, in particular, not known to be > 0. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Hal Finkel Sent: Thursday, July 16, 2015 08:38 To: Raoux, Thomas F Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] LICM for function calls I think we'd need some kind of 'safe_to_speculate' attribute on the function. Regarding the optimization, under what circumstances would you want to speculate a function? I can imagine doing this only if I knew the function would be lowered in the backend to some simple set of instructions. -Hal --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.