[LLVMdev] [Proposal] Speculative execution of function calls

[Renato Golin]

On 31 July 2013 11:56, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote:

> The slightly orthogonal question to safety is the cost of execution.  For
> most intrinsics that represent CPU instructions, executing them
> speculatively is cheaper than a conditional jump, but this is not the case
> for all (for example, some forms of divide instructions on in-order RISC
> processors).  For other functions, it's even worse because the cost may be
> dependent on the input.  Consider as a trivial example the well-loved
> recursive Fibonacci function.  This is always safe to call speculatively,
> because it only touches local variables.  It is, however, probably never a
> good idea to do so.  It's also likely that the cost of a real function call
> is far more expensive than the elided jump, although this may not be the
> case on GPUs where divergent flow control is more expensive than redundant
> execution.  Making this decision requires knowledge of both the target
> architecture and the complexity of the function, which may be dependent on
> its inputs.  Even in your examples, some of the functions are only safe to
> speculatively execute for some subset of their inputs, and you haven't
> proposed a way of determining this.
>

David,

If I got it right, this is a proposal for a framework to annotate
speculative-safe functions, not a pass that will identify all cases. So,
yes, different back-ends can annotate their safe intrinsics, front-ends can
annotate their safe calls, and it'll always be a small subset, as with most
of other optimizations.

As for letting optimization passes use that info, well, it could in theory
be possible to count the number of instructions on the callee, and make
sure it has no other calls, side-effects or undefined behaviour, and again,
that would have to be very conservative.

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130731/13789307/attachment.html>