<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 21 July 2014 19:46, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class=""><br>

<div class="gmail_quote">On Mon, Jul 21, 2014 at 7:31 PM, Nick Lewycky <span dir="ltr"><<a href="mailto:nlewycky@google.com" target="_blank">nlewycky@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>On 21 July 2014 17:08, <a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a> <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br>




<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Use isDereferenceablePointer (which checks things like argument's dereferenceable attribute) in addition to using isSafeToLoadUnconditionally (which is mostly useful for its local instruction scan). Also fixed up one of the test cases.<br>




</blockquote><div><br></div></div><div>The iteration order of the functions within an SCC is non-deterministic and may result in different attributes being added depending on pointer comparison. Consider the case of two leaf functions sharing the same parent, then add call edges between those two "leaf" functions. The df iteration may visit either of those two first, and if one of them depends on the attributes on the other, but the other does not, then you have an order dependence.</div>


</blockquote></div><br></div>Would iterating to fix-point within an SCC be a reasonable solution?</div></div></blockquote><div><br></div><div>It would be correct but wouldn't necessarily fit in O(n^2) time.</div><div>

<br></div><div>There is an efficient fix, it's just time consuming to implement. For a per-function attribute, look at the (function call graph) SCC and determine their attributes as a group, by checking whether any of the functions would fail to have the attributes even if all the others did have the property. If they all would have the attribute when the others do, mark them all as having it. Otherwise, the only way each of them has the attribute is if you could prove it to have the attribute you're looking for even when the other functions in the SCC do not.</div>

<div><br></div><div>You can do this with a local scan of each function up front, breaking them down into a) clearly gets attribute regardless of attributes on other in-SCC functions b) clearly does not get attribute regardless of attributes on other functions c) could get the attribute if the other in-SCC functions do too. You can apply the attribute to anything in category a) immediately, then everything in category c) gets the attribute only if nothing fell into category b.</div>

<div><br></div><div>The dereferencable attribute is not a per-function property, it's a per-argument property, so to handle this you'd need to build up an SCC graph of the arguments. Note that you end up with a forest while scc_iterator requires a connected graph, so in my implementation I add a "synthetic root node", but after that point the rest of the reasoning is the same. I added this to FunctionAttrs.cpp in r147327, if it helps to see an implementation: <a href="http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20111226/134114.html">http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20111226/134114.html</a></div>

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