[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