<p dir="ltr">I will have to check, but still, this seems like an incremental path forward.</p>
<br><div class="gmail_quote"><div dir="ltr">On Sat, Nov 11, 2017, 12:07 Chris Lattner <<a href="mailto:clattner@nondot.org">clattner@nondot.org</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;line-break:after-white-space"><div><blockquote type="cite"><div>On Nov 11, 2017, at 11:06 AM, Chandler Carruth <<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>> wrote:</div><div><p dir="ltr">Internalize can just use target lib info since it sees them still external.</p></div></blockquote></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><div>Good point, doesn’t codegen still recognize some things as well, or does that go through TLI these days?</div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><div><br></div><div>-Chris</div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><div><br></div><br><blockquote type="cite"><div>
<br><div class="gmail_quote"><div dir="ltr">On Sat, Nov 11, 2017, 11:47 Chris Lattner <<a href="mailto:clattner@nondot.org" target="_blank">clattner@nondot.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Nov 10, 2017, at 7:54 PM, Chandler Carruth <<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>> wrote:<br>
> But I think we can combine some of #4 and some of #2 to get a good solution here that is practical and achievable:<br>
><br>
> - Recognize external library functions, much like we already do, but restrict it to external functions.<br>
> - Recognize internal functions *with a builtin attribute* much like we do external library functions.<br>
> - Teach internalize to add the builtin attribute as it changes linkage.<br>
><br>
> One example of what I *really* want from this even in LTO which motivates the change to internalize: things like 'readonly' where some spec lets us optimize callers with this even if the implementation actually writes to memory. Consider building with -fno-math-errno and LTOing a libc that does actually set errno in its implementation.<br>
><br>
> We will also need to constrain optimizations like IPSCCP in the face of internal builtin (and thus library) functions in order to avoid the printf -> puts miscompile described by Eli. But we already have this problem in theory today, and the above won't make it any worse and should even give us new options to address it such as stripping the builtin attribute (in addition to cloning, or other techniques).<br>
<br>
This approach seems like it would work to me!<br>
<br>
The only challenge is that you’ll need a list of “known builtins” that internalize can use, that doesn’t seem like a bad thing though.<br>
<br>
-Chris<br>
<br>
</blockquote></div>
</div></blockquote></div></div></blockquote></div>