[PATCH] D20116: Add speculatable function attribute

Nuno Lopes via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sun Mar 26 08:17:29 PDT 2017


nlopes added a comment.

Let me maybe zoom out and give a different perspective:
Right now call site and function attributes are an AND of predicates that are always guaranteed to hold for that specific call site or for all call sites, respectively.
Predicates include things like doesn't write to memory, only writes to memory that is not observable, etc.  Using attributes we can state that several of these predicates hold.
In the ideal world, predicates wouldn't overlap, although since we can only state ANDs of predicates and not ORs, some overlap may be need in practice.

Then we have an orthogonal concern which is what's the precondition that is sufficient to justify an optimization. For example, whether a function call can be executed speculatively is one of such preconditions. It can be derived by looking at the function attributes.  For example, for speculative execution we probably need to know that the function doesn't write to memory and that it terminates.

So I feel that this speculatable attribute is not the right answer. It should be a helper function that derives its result from a set of function attributes, but shouldn't be an attribute on its own.
The only reason I could see to have it as an attribute would be to carry cost information. Just because a function can be executed speculatively, it doesn't mean it should be.  We have infrastructure to record cost of intra-procedural edges, but not across functions AFAIK. That may need a more general solution for LTO anyway.

I'm just slightly concerned that the set of function attributes is growing pretty quickly without a more throughout discussion of the whole set of attributes rather than adding a new attribute every time someone wants to fix a problem. Some attributes are not well supported across the pipeline.  It really feels like we need to stop for a moment and refactor function attributes.
Probably what we are missing is a "halts"/"terminating" attributes (that states that the function always returns).  It has been discussed multiple times, and now we have another use case.


https://reviews.llvm.org/D20116





More information about the llvm-commits mailing list