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

Chandler Carruth via llvm-dev llvm-dev at lists.llvm.org
Sat Nov 11 11:06:43 PST 2017


Internalize can just use target lib info since it sees them still external.

On Sat, Nov 11, 2017, 11:47 Chris Lattner <clattner at nondot.org> wrote:

> On Nov 10, 2017, at 7:54 PM, Chandler Carruth <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/c5c0f8e4/attachment.html>


More information about the llvm-dev mailing list