That could work!<br><br>But the bigger problem (that I've just remembered) is hooks and callbacks. If a function can either exit, abort or Malloc it could call back into user code. <br><br>That said, those functions (strtok etc) are a smaller subset of the library. <br><br>James<br><div class="gmail_quote"><div dir="ltr">On Tue, 22 Mar 2016 at 07:21, Mehdi Amini <<a href="mailto:mehdi.amini@apple.com">mehdi.amini@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div>On Mar 22, 2016, at 12:09 AM, James Molloy via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div><br><div>Hi,<br><br>On my phone right now but I'll fish out the pertinent threads when I get to the office. Keyword searches for 'norecurse' on llvm-dev will probably get most of them. <br><br>Indeed, this correctness improvement caused a performance regression on some programs. There is a way to revert to the old, broken behaviour: '-mllvm -force-attribute=main:norecurse'. Given how many people run old C code that rely on this property I wouldn't be against adding an appropriate frontend option for this either, but I am not a clang Dev so they might object more :)<br><br>Many library functions can be implemented in a recursive fashion. The issue is the same as we've had elsewhere in LLVM- is there a defined visibility boundary between user and library code? The same problem can be seen in the Malloc attribute annotations (I forget the attribute name) that Vaiva created - having one arbitrary visibility barrier breaks down when libraries are LTOd (bare metal or OpenCl systems being examples)<br></div></blockquote><div><br></div><div><br></div></div></div><div style="word-wrap:break-word"><div><div>By adding the attributes only on libcalls *declarations* only, you solve most of the issues: if you're in the translation unit that exposes the internal implementation of malloc you won't have the attribute (we could imagine that one would implement "strlen" split in multiple files, but that's quite unlikely).</div></div></div><div style="word-wrap:break-word"><div><div><br></div><div>-- </div><div>Mehdi</div></div></div><div style="word-wrap:break-word"><div><div><br></div><div><br></div><br><blockquote type="cite"><div><br>Norecurse as a concept is a trade off between ease of inference and ease of definition. Norecurse is indeed hard for the compiler to infer, but the definition is precise. <br><br>There may be other, superior options - suggestions welcome! :)<br><br>Cheers,<br><br>James<br><div class="gmail_quote"><div dir="ltr">On Tue, 22 Mar 2016 at 01:15, Sanjoy Das via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@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">On Mon, Mar 21, 2016 at 5:34 PM, Chandler Carruth via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> I think the conceptual issues have largely been sorted out, it is mostly<br>
> that it is *much* harder to deduce norecurse than it might seem like<br>
> superficially.<br>
<br>
Is there a specific thread / email I can look at to read about what<br>
the issues were?<br>
<br>
-- Sanjoy<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br></div></blockquote></div></div></blockquote></div>