[PATCH] D20116: Add speculatable function attribute

[Hal Finkel via Phabricator via llvm-commits]

hfinkel added a comment.

In https://reviews.llvm.org/D20116#707120, @sanjoy wrote:

> In https://reviews.llvm.org/D20116#707103, @hfinkel wrote:
>
> > > `readnone` etc. are different from `speculatable`, in that once you mark a call site as `speculatable` you've the said call site as speculatable throughout the lifetime of the program (since, by definition, it can be arbitrarily speculated).  `readnone`, `readonly` etc. do not have that property.
> > > 
> > > But thinking about it a bit, I concede that `speculatable` as a generic (i.e. both intrinsic and non-intrinsic) function attribute is fine.  However, it doesn't make sense as a call site attribute:  being speculatable only down a control flow path is basically the antithesis of `speculatable`.
> >
> > True, but it can still be a callsite attribute. It can represent a data dependency:
> >
> >   int div(int a, int b) {
> >     return a/b;
> >   }
> >  
> >   div(q, 1); /* speculatable */
>
>
> But `div` is not well defined for any possible combination of arguments or global memory state.  I think I understand what you were getting at (that for all values of `q` the expression `div(q, 1)` is well defined), but the LangRef definition mentioned in this change does not phrase things that way.


We might want to adjust the wording. When we say "any possible", for a call site attribute, we mean the values that can possibly present themselves at *that* call site (which may be constrained to be a subset of the values allowed for the input types by the semantics of the program). We mean the same things for other call site attributes (e.g. readnone).

> However, this should be fine IMO:
> 
>   int div_specialized(int a) speculatable {
>     return div(a, 1);
>   }




https://reviews.llvm.org/D20116