<div dir="ltr">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.<div>

<br></div><div>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.</div>

<div><br></div><div>'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.</div>

<div><br></div><div>'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.</div>

<div><br></div><div>No optimizations are included in this patch, this is complicated enough already. Another optimization this will help enable is better memcpy elimination, since we'll be able to show that the users of the memcpy-destination don't mutate it, and with nocapture they don't compare the pointer value itself, and can thus be migrated over to the memcpy-source (assuming the source isn't deallocated). This optimization is also the reason behind the reimplementation of hasPath in <a href="http://llvm-reviews.chandlerc.com/D996">http://llvm-reviews.chandlerc.com/D996</a> .</div>

<div><br></div><div>Please review! Mostly I'd like approval that it's okay to add these new attributes, the implementation isn't as simple as I'd like but the refactoring needed to make it simpler are much too invasive for a drive-by refactoring.</div>

<div><br></div><div>Nick</div><div><br></div></div>