[LLVMdev] [Clang] [lld] [llvm-link] Whole program / dead-code optimization

[ed at modk.it]

Nick,


>  that had me thinking, how do we accomplish the same for unused C++
>> classes or member functions within classes.  I figured we could
>> accomplish that by changing the linkage type within the llvm IR.  But it
>> turns out these already get linkonce_odr linkage.
>> http://llvm.org/docs/LangRef.html states "Unreferenced linkonce globals
>> are allowed to be discarded"
>>
>
> The answer is still internalize. Don't include their names in the list of
> public APIs and they'll be switched to 'internal' linkage, then deleted by
> the LTO passes.
>

Thanks, someone else suggested this but I didn't realize this affected the
link step vs the opt step so I felt it wasn't working.
I'm looking at this now but to be clear, is this known to work with
llvm-lld or just gnu-ld? Your previous answer of "the right future is a
world where lld performs llvm lto for you" had me thinking not to expect
any LTO from lld which is why I've been focused on opt.

>
> There is no representation of a class in llvm or .o files. Instead,
> there's a plain struct which represents the typed memory (ie., storage for
> the non-static data members only), plus a pile of functions which take a
> pointer to that memory as their first argument (the member functions taking
> their 'this' argument).
>

Got it.. You do see a lot of class.xyz references in the llvm assembly so
it's clear what it represents in the C++ code. But I came to C++ from C so
I always think of classes that way anyway ;)



> Note that 'static' functions also just change the linkage to internal. So
> does putting code in an anonymous namespace. The main thing you get out of
> linker integration into LLVM LTO is that the linker can look at the pile of
> non-llvm code and determine which symbols are required by the rest of the
> system and compute that public API list for internalize.
>

What I was surprised about was the effect "inline" has on linkage in C++
and the fact that defining a member function or constructor within the
class body makes it inline.  While I don't understand the choice of the
name inline semantically, it makes sense that member functions defined
within the class body can be removed when not referenced locally since
libraries would certainly provide a header with the definitions in separate
C++ files (how the compiler knew to discard all traces of an unused class
without knowledge of the whole program is what baffled me earlier but makes
sense now).

Thanks,
Ed
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150719/839b33d5/attachment.html>