[llvm-dev] RFC: We need to explicitly state that some functions are reserved by LLVM

Chris Lattner via llvm-dev llvm-dev at lists.llvm.org
Sat Nov 11 11:07:47 PST 2017


> On Nov 11, 2017, at 11:06 AM, Chandler Carruth <chandlerc at gmail.com> wrote:
> Internalize can just use target lib info since it sees them still external.
> 
Good point, doesn’t codegen still recognize some things as well, or does that go through TLI these days?

-Chris


> 
> On Sat, Nov 11, 2017, 11:47 Chris Lattner <clattner at nondot.org <mailto:clattner at nondot.org>> wrote:
> On Nov 10, 2017, at 7:54 PM, Chandler Carruth <chandlerc at gmail.com <mailto:chandlerc at gmail.com>> wrote:
> > But I think we can combine some of #4 and some of #2 to get a good solution here that is practical and achievable:
> >
> > - Recognize external library functions, much like we already do, but restrict it to external functions.
> > - Recognize internal functions *with a builtin attribute* much like we do external library functions.
> > - Teach internalize to add the builtin attribute as it changes linkage.
> >
> > 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.
> >
> > 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).
> 
> This approach seems like it would work to me!
> 
> 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.
> 
> -Chris
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171111/ee4d6e9c/attachment.html>


More information about the llvm-dev mailing list