[cfe-dev] Clang vs MSVC: Smaller objs, but bigger DLLs?

[Reid Kleckner via cfe-dev]

Cool!

Regarding your numbers, I can think of a few differences that might be
relevant.

First, there is /Zc:inline. After inlining, clang discards any unreferenced
inline functions that it can. MSVC doesn't do this as much. In theory, the
/Zc:inline flag exists to enable this behavior, but I've had mixed results.

Next, clang generally inlines more than MSVC. This is just part of the
nature of the bottom-up inliner in LLVM. It lives to remove C++ abstraction
penalty. This can result in larger final code for obvious reasons.
Essentially, if you inline less, there will be more duplicate data in the
object files, which then gets tossed during linking, and then you have a
smaller binary.

I would recommend experimenting with /O1, which is equivalent to -Os in
clang-cl. This is mostly equivalent to -O2 with a lower inlining threshold,
with some additional codegen tweaks in the backend. This should give you a
smaller final binary.

With regard to LLD, I think the size differences come from incremental
linking and whether /OPT:REF and /OPT:ICF are enabled. I think we still
have inconsistencies there. In link.exe, /debug enables /incremental and
disables /opt:ref and /opt:icf. LLD doesn't support incremental linking, so
its /debug output is smaller.

I think this is completely explained in the second table. For debug
binaries, link is bigger because it is incremental. "link ND" and "lld-link
D" are almost identical in size. I think this may be because link.exe isn't
doing ICF, and lld-link /debug disables ICF. Removing /debug and using LLD
enables ICF and GC, and that explains the smaller binary in the "lld-link
ND" case.

---

Finally, given how much smaller the binary with clang objects gets in the
"lld-link ND" case, it sounds like clang is generating a ton of
unreferenced code and data for your codebase. It's not immediately clear
what's causing that. You can get some visibility into it by linking with
/verbose, and that will show you what's being discarded.

On Thu, Jan 18, 2018 at 11:42 AM, Cullen, Colden via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> Hey everyone,
>
> First of all, thanks to everyone who's given me feedback on the patches
> I've posted recently! I really appreciate you taking the time to review my
> code.
>
> For context, I work on Amazon Lumberyard, and my current goal is to get
> the entire engine and toolset to build on Windows with Clang and LLD as an
> alternative to MSVC. So far I've made a ton of progress; I've fixed a few
> bugs in LLVM, and fixed an uncountable number of bugs and warnings in our
> codebase that slipped past other compilers.
>
> The most recent issue I've run into is quite perplexing. When building our
> largest legacy DLL, I see the following behavior:
> - The .obj files produced by Clang are about half the size of the
> corresponding MSVC objects (719 files, 17.2GB from MSVC, 8.9GB from Clang)
> - Linking the MSVC set of object files with both linkers with or without
> /DEBUG is successful
> - Linking the Clang set of object files with LLD without /DEBUG is
> successful
> - Linking the Clang set of object files with MSVC's link.exe with or
> without /DEBUG and with LLD with /DEBUG results in a "binary too large"
> error.
>
> Here's a table of linker, Debug or No Debug, and resulting binary size for
> the Clang object files:
> link.exe D:  4297254686 (reported)
> link.exe ND: 4295125179 (reported)
> lld-link D:  5558142976 (reported)
> lld-link ND:   77908000 (on disk)
> MAX SIZE:    4294967295
>
> And here's the results for the MSVC object files:
> link.exe D:   135228416 (on disk)
> link.exe ND:  109041152 (on disk)
> lld-link D:   109095424 (on disk)
> lld-link ND:   84219904 (on disk)
>
> Clang and LLD are built from trunk, and I'm running both linkers with the
> following options:
> /MACHINE:x64 /MANIFEST /LARGEADDRESSAWARE /DEFAULTLIB:msvcrtd
> /SUBSYSTEM:WINDOWS /NODEFAULTLIB:LIBCMTD.lib /DLL /TIME /ignore:4099
> [/DEBUG]
>
> I'm going to start poking around object files to see what I can learn, but
> does anyone have any tips on debugging something like this? I honestly
> don't really know where to start.
>
> If this turns out to be extra troublesome, I can work on getting legal
> approval to share my compiled objects to help you repro it. That can be a
> tricky process, so I'd like to just debug vicariously if possible.
>
> Thanks!
> Colden Cullen
> colden at amazon.com
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180118/a4282448/attachment.html>