[PATCH] D20116: Add speculatable function attribute
Daniel Berlin via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Sun Mar 26 14:54:01 PDT 2017
dberlin added a comment.
> I think that all of this is right, you can't apply some of these optimizations to call sites with the speculatable attribute.
A lot of these (but not all of these) amount to "you cannot clone speculable", ie if you clone the call, you must remove the attribute.
I believe the set of conditions under which you could clone the attribute are:
1. The new call is CDEQ the original call (IE the set of conditions under which it executes is identical). IF you are cloning from one function to another, it must be CDEQ using the interprocedural control dependence.
2. The arguments are identical.
3. The function called is identical or marked speculable
Note this is not entirely shocking,.
the "no cloning" is true of other attributes (you can't clone and apply readonly like is done in the devirt example above) , it's just that, being an attribute about control dependence, the effects relate to control dependence.
Note: a lot of this is premature anyway. There is no possible way you could ever apply any of these optimizations correctly to speculatable, at all, until we fix post-dom to not be broken.
> I agree, however, that we need to think carefully about how to define what speculatable means on an individual call site. Perhaps they're like convergent functions in this regard: you can't introduce new control dependencies (at least not in general).
Either the CDEQ set of the call must not change , or you must be able to prove that changes cannot impact the function (IE you don't make it any less dead, etc).
const int foo = bar = fred = 0;
call baz() speculatable
You can prove hoisting into if (foo) cannot make it any less dead.
More information about the llvm-commits