[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:14:20 PST 2017


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>


More information about the llvm-dev mailing list