[llvm-dev] RFC: We need to explicitly state that some functions are reserved by LLVM
Hal Finkel via llvm-dev
llvm-dev at lists.llvm.org
Thu Oct 26 21:01:30 PDT 2017
On 10/26/2017 10:56 PM, Chris Lattner via llvm-dev wrote:
>
>> On Oct 26, 2017, at 8:14 PM, Chandler Carruth via llvm-dev
>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>>
>>
>> One alternative that seems appealing but doesn't actually help would
>> be to make `TargetLibraryInfo` ignore internal functions. That is how
>> the C++ spec seems to handle this for example (C library function
>> names are reserved only when they have linkage). But this doesn't
>> work well for LLVM because we want to be able to LTO an internalized
>> C library. So I think we need the rule for LLVM function names to not
>> rely on linkage here.
>
> Oh sorry, (almost) TLDR I didn’t get to this part. I don’t see how
> this is applicable. If you’re statically linking in a libc, I think
> it is fine to forgo the optimizations that TargetLibraryInfo is all about.
>
> If these transformations are important to use in this case, we should
> invent a new attribute, and the thing that turns libc symbols into
> internal ones should add the attribute to the (now internal) libc symbols.
I'm not sure; some of the transformations are somewhat special (e.g.,
based on mathematical properties, or things like printf -> puts
translation). LTO alone certainly won't give you those kinds of things
via normal IPA, and I doubt we want attributes for all of them. Also,
having LTO essentially disable optimizations isn't good either.
-Hal
>
> -Chris
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171026/6f3631a0/attachment.html>
More information about the llvm-dev
mailing list