Questions about Clang on Windows

176 views
Skip to first unread message

Rong Jie

unread,
Jun 17, 2017, 5:43:31 AM6/17/17
to Chromium-dev
Hi all,

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):
  • MSVC:8702KB
  • 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?

Build details.
  • 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)
clang version 5.0.0 (http://llvm.org/git/clang.git 49b5e3a4247d0525c7f6de9c4fe955d5610bfbe8)
(http://llvm.org/git/llvm.git 4d07d46bb1da239a2066cb9cf6f3daa13187b4e5)
Target: x86_64-pc-windows-msvc
Thread model: posix

Slight-unrelated:

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.

Nico Weber

unread,
Jun 17, 2017, 11:24:34 AM6/17/17
to looro...@gmail.com, Chromium-dev
Hi Rong,

On Sat, Jun 17, 2017 at 5:43 AM, Rong Jie <looro...@gmail.com> wrote:
Hi all,

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)
We've given a few presentations on this project at the LLVM developer conference, some of which included bits on motivation. This last one here doesn't, but it includes links to the previous presentations: https://docs.google.com/presentation/d/1oxNHaVjA9Gn_rTzX6HIpJHP7nXRua_0URXxxJ3oYRq0/edit#slide=id.p

A few more reasons off the top of my head are:
- Deterministic builds (link.exe /incremental requires each .obj file to contain a timestamp to work – admittedly more a linker than a compiler thing)
- cs.chromium.org's indexing is built on clang, so if we want to index chrome/win code we need clang support
- Likewise, things like chromium's style plugin and tooling (which we e.g. used to rewrite scoped_ptr to unique_ptr and other things) require clang
- Having an open-source compiler is nice
 
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):
  • MSVC:8702KB
  • 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)?

We've been focusing on the size of chrome. https://crbug.com/457078 is the tracking but, it contains lots of numbers, graphs, etc.

agrieve@ did an analysis of the size savings when switching chrome/android to clang here: https://bugs.chromium.org/p/chromium/issues/detail?id=656048#c1 The takeaway seems to be that clang emits pretty small code when optimizing for size but larger code when optimizing for speed. In chrome, we build perf-critical parts (like v8) optimized for speed but most code optimized for size, which might explain what you're seeing. If you care about size a lot, you could change v8's optimization setting.
 
Also, LLD is certainly not performing very well here.

Which version of LLD did you use? use_lld is still a lot less mature than clang-cl, so we haven't looked at things like size and whatnot with it yet.
 
I am not sure how to compare the performance of the final executables. Any public data from chromeperf.appspot.com?

You can send a perf tryjob with is_clang=true on Win yourself if you want, see https://bugs.chromium.org/p/chromium/issues/detail?id=481675#c31 for how. 

One or two weeks ago we turned on is_clang=true on Win by default over a weekend, here's the perf bots during that range: https://chromeperf.appspot.com/group_report?rev=476884 (the non-win entries are obviously unrelated, so you can tell that there's some noise).
 

Build details.
  • 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)
clang version 5.0.0 (http://llvm.org/git/clang.git 49b5e3a4247d0525c7f6de9c4fe955d5610bfbe8)
(http://llvm.org/git/llvm.git 4d07d46bb1da239a2066cb9cf6f3daa13187b4e5)
Target: x86_64-pc-windows-msvc
Thread model: posix

Slight-unrelated:

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.

https://groups.google.com/a/chromium.org/forum/#!topic/gn-dev/fjm5lQSX4l8 discusses how you can set clang_base_path. But note that you don't have to set this at all, we bundle a clang with the Chromium checkout, and if you don't set clang_base_path, it'll point to the bundled clang by default (it gets downloaded to third_party/llvm-build/Release+Asserts/bin).

Nico 
Reply all
Reply to author
Forward
0 new messages