patch: add readonly argument attribute
Chris Lattner
clattner at apple.com
Thu Jul 4 14:13:19 PDT 2013
Hi Nick, here's a quick concept review:
On Jul 3, 2013, at 9:27 PM, Nick Lewycky <nlewycky at google.com> wrote:
> The attached patch implements support for 'readonly' and 'readnone' on individual pointer-typed attributes. The llvm memcpy/memmove intrinsics are given readonly on their source pointers, and FunctionAttrs is updated to label known functions with readonly/readnone where appropriate, as well as deduce the attributes from function bodies. The semantics are described in the patch to LangRef.
Ok, how does this compare to AliasAnalysis::ModRefBehavior? Can we merge those concepts into this eventually?
> These attributes don't permit any new optimization of the function to which they are applied. They do allow optimization to be applied in the caller of the function, when the pointer has not otherwise escaped.
>
> 'readonly' can be used to allow store-load propagation and load-load folding across calls. It requires knowing that the callee can't have the pointer through some other means (we already have capture tracking). This shows up a lot in of C++ code that takes a "const Foo &" argument.
>
> 'readnone' is really just along for the ride since I'm adding 'readonly' anyways, but if you'd like a justification it means the pointer isn't dereferenced but may be compared. Consider std::set<char*>, which requires a comparison operator<(char *lhs, char *rhs); That function would have 'readnone' on lhs and rhs. Furthermore, a nocapture readnone argument is a dead argument.
Sure, these seem fine. If you complete the set with a "readwrite" and "writeonly" attribute, you can more precisely model mod/ref behavior, and would allow you to introduce a function attribute analogous to "OnlyAccessesArgumentPointees". This would basically say that the function/intrinsic *only* affects declared arguments, not global memory.
Modeling these things properly would be useful for a lot of things, and should allow elimination of some of the special cases for intrinsics at the end of BasicAliasAnalysis::getModRefInfo.
-Chris
More information about the llvm-commits
mailing list