Questions about Clang on Windows

[Rong Jie]

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]

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:

- CFI (https://www.chromium.org/developers/testing/control-flow-integrity)

- 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