Hacker News Reader

Comment by sevagh | Hacker News Reader

Are vendor-specific compilers generally clang-based? Emcc (emscripten), aocc (AMD), now vcc (Vulkan). I'm not sure about nvcc (NVIDIA) or icc (Intel)

View on HN

Intel's modern compilers (icx, icpx) are clang-based. There is an open-source version [1], and the closed-source version is built atop of this with extra closed-source special sauce.

AOCC and ROCm are also based on LLVM/clang.

[1] https://github.com/intel/llvm

I forgot to ask my question which was "why are vendor compilers based on clang over gcc", but it must be related to LLVM?

If I had to guess, permissive licensing, better platform support, and the perception of LLVM being easier to target than GCC.

LLVM is a big part of it. GCC is more opaque (and monolithic) in comparison. Having an intermediate language and a modular architecture makes it easier to build specialized compilers.

Another selling point is the Clang CFE, which amortizes the complexity of C++ parsing and semantic analysis, much to the chagrin of the Edison Design Group.

Meanwhile EDG are the ones coming up with an usable reflection proposal for C++26, and since Apple and Google stepped out, not many of those profiting from clang are that eager to contribute to upstream fronted.

I was surprised to see they were even still active, much less leading the way on reflection. Hopefully they will manage to stick around.

Anyway, such a pessimistic view of Clang/LLVM is unwarranted IMO. I have yet to see any metrics that imply their abandonment. Also, considering that Google is likely closer to 300 million LOC than 200 million, they really don't have a choice. Likewise for Apple unless they’ve given up on WebKit and LLVM for Swift.

One metric is the amount of red in cppreference.

Apple and Google are perfectly fine with C++17 for their purposes, which is the version used by LLVM to compile itself.

One metric is the amount of red in cppreference.

Sometimes one implementation's red box is better than another implementation's green box.

Clang supports the majority of C++20. The biggest blocker on coroutines is a Windows ABI issue and concepts will be ready after a few DRs are polished off. Basically, other than some minor CTAD and non-type template parameter enhancements, the biggest feature lagging behind are modules. IMO, I'm not ready for modules, my dependencies are not ready for modules, neither is my IDE nor my build system. So, for my interests, C++20 support in Clang is more than sufficient.

Apple and Google are perfectly fine with C++17 for their purposes, ...

Well, yes, and they will likely be using C++17 for quite a bit longer. In particular, not only is C++20 a massive update to the language, but the rate of development in the llvm-project has far exceeded the rate at which maintenance capacity can be increased. Not to mention a myriad of other issues, notably the architectural problems in Clang.

LLVM is a library for building compilers, GCC is not.

It's pretty much that simple.

It is called GNU Compiler Collection for a reason.

LLVM is so much easier to work with.

You can get started on reasonable optimizations and be done with a prototype in hours, compared to days or weeks in gcc.

Also Microsoft DirectX Shader Compiler[1] for HLSL. In fact, effort is ongoing to upstream HLSL support into Clang.[2][3][4]

To answer your other question—why LLVM instead of GCC:

- First-class support for non-Unix/Linux platforms. LLVM can be built on Windows and Visual Studio without ever needing a single GNU tool besides git[5]. Clang even has a MSVC-compatible interface that allows MSVC developers to switch to Clang without needing to change their command-line invocation[6].

- Written in C++ from the ground up, with a modular, first-class SSA IR-based interface.

- Permissive Apache 2.0 licence. As much as this might exasperate the open-source community, it allows for significantly faster iteration; things tend to be upstreamed when private/corporate developers realise it is hard to maintain separate forks.

All this allows LLVM to have a pretty mature infrastructure; some very large companies have contributed to its development.

[1]: https://github.com/microsoft/DirectXShaderCompiler

[2]: https://clang.llvm.org/docs/HLSL/HLSLDocs.html

[3]: https://github.com/microsoft/DirectXShaderCompiler/wiki/Cont...

[4]: https://discourse.llvm.org/t/rfc-adding-hlsl-and-directx-sup...

[5]: https://llvm.org/docs/GettingStartedVS.html

[6]: https://clang.llvm.org/docs/UsersManual.html#clang-cl

> without ever needing a single GNU tool besides git[5]

Since when is git GNU?

My bad—I meant GPL.

Written in C++ from the ground up, with a modular, first-class SSA IR-based interface.

LLVM IR is a great accomplishment, but the design of Clang causes tremendous pain. In particular, the lack of any higher level IR(s) in Clang result in tremendous complexity, poorer diagnostics, and missed performance optimizations. Moreover, while initiatives like ClangIR[1] may exist, the fact is that a transition to MLIR will be long and messy, to say the least. Indeed, such a transition would likely involve the complete duplication of Clang internals while downstream implementations migrate. In comparison an implementation like GCC is free to define and modify new IRs as needed, e.g. GIMPLE has three major forms IIRC.

[1]: https://llvm.github.io/clangir//

Reply on news.ycombinator.com