I know Chrome is working very hard to use Clang on all platforms. Linux, Mac and recently Android's official binaries now use Clang.
Even Windows is in the plan. I asked a Chrome eng about why use Clang on Windows and here are reasons I was given:
- Control of toolchain (Agreed: get fresh master clang weekly and report/fix bugs quickly)
- ASAN (Agreed: better than MSVC + SyzyASAN
- C++ conformance (Agreed: MSVC still lack two phase lookup for templating)
But I remain doubtful with the last reason: smaller x64 code.
To put this on a test, I tried to build V8 (master):
Size of d8.exe (V8 shell):
- is_clang: 8981KB
- is_clang + use_lld: 15510KB
So maybe the "smaller x64 code" only applies when building Chrome as a whole instead just one component (V8)? Also, LLD is certainly not performing very well here.
I am not sure how to compare the performance of the final executables. Any public data from chromeperf.appspot.com
- gn args: is_debug=false v8_enable_handle_zapping=false target_cpu="x64" v8_enable_i18n_support=false v8_enable_disassembler=true
- Visual Studio 2017 RTM
- Windows 10 SDK Anniversary Update
- Clang 5.0.0 (bootstrap locally)
V8 source code lives in D:\ while clang lives in C:\, so when I set clang_base_path in GN, GN tries to generate relative path from V8 build directory to clang directory like ../../../../C:/path/to/clang, but this relative path is invalid, you can't switch drive like that.
I worked around this by making symlink in D:\ to point to C:\path\to\clang and set clang_base_path to this symlink instead. I think clang_base_path should just take the path as-is or resolve it to absolute path before writing it into toolchain.ninja.