<div dir="ltr">Hi David,<div><br></div><div>So in that case it would be legal for f() to be marked norecurse (although my implementation in FunctionAttrs is more conservative than that, but that's what the LangRef says). However I'm not sure exactly how inlining could break this assumption - recursive inlining would end up with something like (modifying your testcase slightly):</div><div><br></div><div>f() {</div><div>  a()</div><div>  g()</div><div>}</div><div><br></div><div>g() {</div><div>  a()</div><div>  g()</div><div>}</div><div><br></div><div><br></div><div>which doesn't break at all.</div><div><br></div><div>James</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, 2 Nov 2015 at 20:39 David Majnemer via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">majnemer added a subscriber: majnemer.<br>
majnemer added a comment.<br>
<br>
James,<br>
<br>
Have you considered what happens with something along the lines of:<br>
<br>
  void f() {<br>
    g();<br>
  }<br>
  void g() {<br>
    g();<br>
  }<br>
<br>
In this case, we can clearly see that `f` doesn't recurse onto itself but `g` does.<br>
<br>
I am concerned that if we infer `norecurse`, we will hit cases where transformations along the lines of inlining invalidate the attribute.<br>
<br>
<br>
Repository:<br>
  rL LLVM<br>
<br>
<a href="http://reviews.llvm.org/D14227" rel="noreferrer" target="_blank">http://reviews.llvm.org/D14227</a><br>
<br>
<br>
<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br>
</blockquote></div>