Not having to worry about language feature support across different compilers is a big win. See https://bugs.chromium.org/p/libyuv/issues/detail?id=685 for one specific example of why using Clang can have benefits over MSVC (TL;DR: 64-bit MSVC doesn't support inline assembly). Clang was already being used to compile this little part of Chrome on Win64.

Switching to Clang also allows the use of Clang-based sanitizers and fuzzing, which improves the security of Chrome.

> 64-bit MSVC doesn't support inline assembly

Wow. That's a big omission on Microsoft's part! I wonder how they themselves are getting around it for Win64 performance sensitive code.

IIRC, Microsoft wants you to use intrinsics because it plays better with their register coloring and code reordering optimizations.

Unless there's an instruction you need that doesn't have an intrinsic or you're writing something like a spin lock where instruction ordering is critical and a compiler barrier for some reason is not sufficient, there's no reason to ever write assembly.

Your code won't be appreciably faster than if you tuned it in the compiler, and after a few years the compiler will integrate new instructions while your assembly just gets stale.

> Unless there's an instruction you need that doesn't have an intrinsic or you're writing something like a spin lock where instruction ordering is critical and a compiler barrier for some reason is not sufficient, there's no reason to ever write assembly.

So there are reasons to write code in assembly language.

OK, there's no reason for YOU to write code in assembly.

For me, personally? I occasionally can write that kind of stuff.

You can still write routines in assembly, you cant write it inline.

You can also use intrinsics if you don't want to write your entire routine in assembly.

You are supposed to use special MASM directives to generate function tables for SEH.

There are few reasons to use assembly, and even fewer to use inline assembly

Using CPUID is one, using very specific vector instructions another (but you can do most of this using intrinsics) and it's better if they get their own .s file

inline assembly e.g. intermixed with C/C++ code is not supported. You can still have separate files that are ASM only.

It's more hassle, but still possible to use.

> So what is Chromium gaining from switching to clang-cl?

There are lots of good reasons, but my favourite point -- besides considering clang to be a superiour c++ compiler in general -- is that using an open-source compiler allows us to fix things.

When a developer runs into a miscompile or compiler crash, finds an inefficiency in the generated code or has an idea for a new warning, we can fix it and push a new compiler out within days. And in addition to the work we put in ourselves, we benefit from the huge amount of work put in by the wider llvm/clang community.

It leads to a better developer experience, and in the end a better product.

Two other reasons that haven't been mentioned yet:

- MSVC had trouble with dead code elimination in some cases: fixing https://crbug.com/684105 reduced binary size by almost 900KB on Windows.

- It lets tooling like https://chromium.googlesource.com/chromium/src/+/master/docs... and the custom clang plugin checks run on Windows-specific code.

As far as I'm aware, there are no downsides to switching to Clang on Windows. Clang produces VS-compatible debug info, it's integrated perfectly fine into VS. In addition, you don't need a VS license to compile the desired 64-bit Windows binaries. In addition, the code generated is typically faster and smaller. They get to use new C++ features without waiting for a major VC++ release. They can hope to do cross compilation on an operating system with a filesystem that isn't outrageously slow. They can stop having to put in VS-specific warning disables and go with the GCC-Clang standard ones. Clang is also just faster to run in general. They get to use one compiler on every platform, and when they improve the compiler, it helps all of their platforms.

Seems like a win on every level to me.

Not a win on every level: As the link says, clang is slower than Visual Studio's compiler.

But on the other hand Microsoft's compiler, linker, headers, debuggers are tested together for the OS releases they support. clang-cl doesn't have that advantage. I guess Google is picking up clang-cl maintenance to make sure it remains compatible with various dependencies MS changes.

Microsoft endorses and works on clang-cl, though I wouldn't say they give it as much attention as their own compiler. As for compatibility, I don't think it's a huge issue, if they never changed the compiler again, it would probably still generate working binaries for the next decade, including PDBs.

According to the first post in the linked thread, the switch to clang is transparent enough that the VS IDE-based debugging experience still works.

My guess (not being a Chromium developer myself) is that this is an exercise in consistency across platforms - I can imagine that using the same compiler on all supported platforms makes the language features supported consistent and removes the risk of one compiler generating much worse output for the same code. But I'm just postulating, I don't actually know for sure.

One reason is to use AddressSanitizers, ThreadSanitizers, static analysis and other tools clang and LLVM bring.

That's a good point. It's good enough a reason to be able to run AS/TS on Windows code base. Not actually sure it works on Windows though.

Google is the original writer or significant contributor of these tools. So presumably they first get clang work properly on Windows, then port these tools to Windows, then profit.

If you live in an "all compiler warnings are errors" world, having two compilers where a bit of code can cause a warning in one compiler and not cause a warning in another compiler is really annoying.

And this is why the intersection area in the Venn diagram of "people that use -Werror" and "people that use multiple compilers" is labeled "people who are making their own lives difficult, for no obvious reason".

By different you also mean different versions, right?

Yes, sure - any time different people will be getting different sets of warnings, -Werror (or equivalent) is just going to make your life harder.

You should always strive for zero warnings on all builds across all compilers. It's a realistic, achievable and worthwhile goal. But while pretty much all warnings are worth looking at, a much smaller set are worth breaking the build over. You're much better off (in my view) promoting those particular warnings to errors, and leaving the rest as-is.

Presumably end users who are compiling from source wouldn't want to enable -Werror though.

If you are an application developer and a compiler X gives warnings that compiler Y doesn't for your application, then ideally you should probably fix the warnings from compiler X. An end user probably doesn't care either way, they just want to compile the program without any issues.

Realistically, though, an end user doesn't compile anything these days. If you build Chromium from source you're at least half interested in tinkering with it.

Well certain Linux distros (Gentoo comes to mind) are designed to support their users compiling applications from source. Some users just want to be able to compile using -march=native, and aren't interested in fixing compiler warnings that they didn't introduce. I personally would hate it if I wanted to compile an application from source but -Werror stopped complication through no fault of my own.

Using fewer compilers has obvious benefits to the software development and production process. E.g. no need to fix code when a checkin from developer on Platform X breaks the build on Platform Y.

I'd be curious if it robs it of some benefits, though. The process you describe above sounds like it might actually be beneficial in an "antifragile" kind of way.

That is, there are benefits to be had by knowing you do work on multiple toolchains. Painful at times, but mainly in ways that make a better product.

I don't know how the Chromium project is set up, but another way to achieve that benefit is to require that succeed on all platforms before code can be checked in. Which you should probably do anyway.

They do that, but for the programmers it's still annoying (and a waste of time) to have patches rejected because some compiler on some platform behaves differently.

This might answer your question: https://groups.google.com/a/chromium.org/d/msg/chromium-dev/...

Clang is generally a better compiler that produces faster code (with some exceptions).

I agree that it is a better compiler, but have heard mixed results on whether it produces faster code. Do you have a citation?

I'm basing this assessment mostly on my own experience and testing. In terms of performance difference, it can be hard to compare since Clang-compiled programs often run on Linux, and MSVC programs run on Windows, so it's difficult to factor out the perf differences due to the OS. However I have measured one of our programs running significantly faster in a Linux VM, compiled in Clang, running with Windows as a host OS, than the program compiled with MSVC running directly on Windows.

In addition, the analyses and optimisations performed by Clang are generally more sophisticated than by MSVC. See for example http://www.forwardscattering.org/post/51.

The only optimisation I know of that MSVC performs that Clang doesn't (in some cases at least) is autovectorisation of some maths functions: https://bugs.llvm.org/show_bug.cgi?id=23645

(Actually MSVC has a pretty effective link-time code gen option, that is often turned off by projects using Clang)

One compiler for all platforms is a major win.

The post says that the debugging experience stays... so perhaps clang outputs PDBs now, and/or you can interface it with Windows gdb somehow.

CodeView debug info is supported in Clang.

See https://www.youtube.com/watch?v=5twzd06NqGU

Will the reliance on recent msvcredist (Visual c++ redistributable) be gone too with the move to Clang?

Their 2015 (and later) tooling and runtime cannot be trusted anymore, they send home data like there is no tomorrow - as observed on Win7. It's the VC++ runtime, the dotNet runtime, the dotNet optimization process, VSCode, dotNetCore, etc all send data home with no opt-in or opt-out option. This doesn't happen on other operating systems.

No. clang on Windows is only a compiler. No SDK or runtime libraries are included.

Did this come with the switch from msvcrtNNN.dll to ucrt.dll, which is the more POSIX compliant runtime?

Same compiler on all platforms would be one guess.

> So what is Chromium gaining from switching to clang-cl?

Slower build times.