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

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>

> 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>

I will have to check, but still, this seems like an incremental path
forward.

On Sat, Nov 11, 2017, 12:07 Chris Lattner <clattner at nondot.org> wrote:
> 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>
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/1b8442c0/attachment.html>