Chromium Windows builds now use Clang by default | Hacker News Reader

Chromium Windows builds now use Clang by default

groups.google.com

118 pointsevmar58 comments

Hmm. I went through the thread and could not find an answer to the question - why? Using platform's default compiler would be the safest thing to do and MS is making good progress with VC as far as adding standards support goes. They have been receptive of bug reports and relatively quick at fixing them too as far as I remember. Switching to clang also takes away the nice VS IDE based debugging experience [turns out it doesn't, I misread the post as saying you can still compile and debug with VS].

So what is Chromium gaining from switching to clang-cl? Perhaps just less amount of compiler specific code/hacks/quirks/workarounds etc?

Edit: This being Google I was expecting interesting data or at least somewhat thorough reasoning. The post just felt like a fyi for switching to clang. Nonetheless some good possible reasons in below replies.

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.

One compiler for all platforms is a major win.

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.

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

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

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.

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.

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.

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.

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.

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

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.

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.

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

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.

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.

Same compiler on all platforms would be one guess.

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.

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

Slower build times.

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?

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)

They can distribute the build over multiple machines easier with clang. That is reason enough for the move.

Uh oh, I have been putting a lot of effort embedding Chromium with Qt (which does not AFAIK have a clang build). I am afraid this is really going to slow me down. I wonder how this will harm other developers using CEF [0] w/ MSVC.

0 - https://bitbucket.org/chromiumembedded/cef

Edit: Now that I think about it, the Qt stuff is all in shared libs, so less worried there. But with CEF, the C++ wrapper is statically linked. What is MSVC's linker's ability to consume clang objs and vice versa I wonder. If not an issue, maybe I'm just fine.

I did a CEF-based project last year. I didn't built Chromium myself; I used a pre-build copy, from Spotify I think. The CEF build process sets this all up for you, so I expect this is typical. So this should mean that provided the clang builds of Chromium look the same to the outside world as the VC++ builds of Chromium, there won't be a problem.

(It works well. The PDB files and the corresponding source code are available, so you can step through the Chromium code in Visual Studio and so on.)

CEF is built as part of your program using whatever compiler you're using. I don't know what the mechanics of it are... I assume it uses the Chromium stuff via an import library? I didn't look very closely at this aspect of it.

Right, but CEF uses cmake w/ msvc customizations IIRC. And the spotify builds do ship with the DLLs already built. I asked on the CEF forum just now, we'll see.

Chromium will continue using link.exe as the linker even after migrating to clang-cl. See the bottom of the email that's linked.

CEF goes to great pains to export a stable C ABI, not a C++ one, from the DLL. So I think you'll be fine.

Qt5.9 comes with windows clang spec for qmake. Previously you could setup it on your own in windows and Linux wasnt probably that hard either. For OS X "clang" was always a default.

Hopefully this is a step towards QtWebEngine (Blink) on the open source distribution of Qt on Windows. Right now you are limited to QtWebKit.

Clang targets webassembly, doesn't it? If so, does that mean it will soon be possible to browse the web with chromium running inside other browsers? That'd be fun.

https://trevorlinton.github.io/

That is scary when you consider the DRM implications.

Wasn't it STL who said recently that clang/cl experimentation is finished and recommended to use clang from llvm for windows instead?

The mentioned clang-cl is the clang driver with MSCV-compatible options and LLVM backend, not the clang/c2 with the MSVC backend.

Reply on news.ycombinator.com