<div dir="ltr">Cool!<div><br></div><div>Regarding your numbers, I can think of a few differences that might be relevant.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>---</div><div><br></div><div>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.</div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span></span></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 18, 2018 at 11:42 AM, Cullen, Colden via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey everyone,<br>
<br>
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.<br>
<br>
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.<br>
<br>
The most recent issue I've run into is quite perplexing. When building our largest legacy DLL, I see the following behavior:<br>
- 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)<br>
- Linking the MSVC set of object files with both linkers with or without /DEBUG is successful<br>
- Linking the Clang set of object files with LLD without /DEBUG is successful<br>
- 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.<br>
<br>
Here's a table of linker, Debug or No Debug, and resulting binary size for the Clang object files:<br>
link.exe D:  4297254686 (reported)<br>
link.exe ND: 4295125179 (reported)<br>
lld-link D:  5558142976 (reported)<br>
lld-link ND:   77908000 (on disk)<br>
MAX SIZE:    4294967295<br>
<br>
And here's the results for the MSVC object files:<br>
link.exe D:   135228416 (on disk)<br>
link.exe ND:  109041152 (on disk)<br>
lld-link D:   109095424 (on disk)<br>
lld-link ND:   84219904 (on disk)<br>
<br>
Clang and LLD are built from trunk, and I'm running both linkers with the following options:<br>
/MACHINE:x64 /MANIFEST /LARGEADDRESSAWARE /DEFAULTLIB:msvcrtd /SUBSYSTEM:WINDOWS /NODEFAULTLIB:LIBCMTD.lib /DLL /TIME /ignore:4099 [/DEBUG]<br>
<br>
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.<br>
<br>
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.<br>
<br>
Thanks!<br>
Colden Cullen<br>
<a href="mailto:colden@amazon.com">colden@amazon.com</a><br>
<br>
______________________________<wbr>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
</blockquote></div><br></div>