Hi Nick, here's a quick concept review: On Jul 3, 2013, at 9:27 PM, Nick Lewycky <[email protected]> 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 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
