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

[Friedman, Eli via llvm-dev]

On 10/26/2017 9:01 PM, Hal Finkel via llvm-dev wrote:
>
>
> 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.

Given the way the optimization pipeline works; we can't treat an 
"internal" function as equivalent to a C library function.  When the 
linkage of a function becomes "internal", optimizations start kicking in 
based on the fact that we can see all the users of the function.

For example, suppose my program has one call to puts with the constant 
string "foo", and one call to printf which can be transformed into a 
call to puts, and we LTO the C library into it. First we run IPSCCP, 
which will constant-propagate the address of the string into the 
implementation of puts.  Then instcombine runs and transforms the call 
to printf into a call to puts.  Now we have a miscompile, because our 
"puts" can only output "foo".

Given we have mutually exclusive optimizations, we have to pick: either 
we allow the IPSCCP transform, or we allow the instcombine transform.  
The most straightforward way to indicate the difference is to check the 
linkage: it intuitively has the right meaning, and our existing 
inter-procedural optimizations already check it.

-Eli

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171027/1afb2a67/attachment.html>