[llvm-commits] [llvm] r154645 - /llvm/trunk/lib/Transforms/IPO/Internalize.cpp

[Bill Wendling]

On Apr 15, 2012, at 7:02 PM, Rafael Espíndola wrote:

>>> Could you use TargetLibraryInfo? If not, the best place would probably be an API to the backend. Anyhow, please move this to libLTO's applyScopeRestrictions at least. It doesn't belong here.
>>> 
>> I don't see why it shouldn't be here. Other implementations which use the Internalize pass don't necessarily need to use the LTO interface, but should have these symbols remain nonetheless.
> 
> 
> I agree that this should not be in libLTO. Think for example of lld,
> it should be able to use this without using a C api.
> 
> I do agree that this place is also not great. Can you add a FIXME with
> Nicks suggestion of moving this to an backend API?
> 
Okay.

> btw, don't you also need to this information to let the apple linker
> know that a new undefined reference might show up? For example, what
> happens if you a static linking libc, you program has no call to
> memcpy but CodeGen introduces one? Will the linker correctly fetch the
> archive member?
> 

The libc calls that LLVM conjures up are looked for in a separate pass. So those calls don't need to be added here. The stack guard call isn't part of libc, so the linker doesn't look for it, which is why I needed to add it here. But because there's a use of the symbol, the linker won't remove it even though it's not in one of its export lists.

-bw