> Edit: OpenVMS maybe, but not sure whether that qualifies for in wider use
In the x86-64 port, they've been moving OpenVMS to use LLVM too. With the VAX->Alpha port, DEC introduced a common backend for all their OpenVMS compilers, called "GEM". For the Alpha->Itanium port, Compaq/HP kept the GEM backend but modified it to generate Itanium code instead of Alpha.
For the x86-64 port, instead of investing in modifying "GEM" to support x86-64, VSI decided to use LLVM as a backend, and then write a translator from GEM's intermediate representation to LLVM's. So they keep the same frontends as before – except for C++, where they replaced the EDG/Intel frontend with LLVM – but now use LLVM as a backend. https://llvm.org/devmtg/2017-10/slides/Reagan-Porting%20Open...
OpenVMS has a somewhat unusual ABI. For x86-64 they've tried to make it more consistent with the standard Linux x86-64 ABI, but there remain some distinctive features. One feature (which I actually really like, I think it is a shame that other ABIs don't do this), is that variadic function calls pass the argument count in a register (%rax on x86-64). Another is that all functions must have a 32-bit address; the code of a function can be allocated above 4GB, but they allocate a trampoline under 4GB which jumps to its actual code – this was done to simplify interoperability between 32-bit and 64-bit code in the same address space. https://docs.vmssoftware.com/vsi-openvms-calling-standard
IBM still has their classic XL C/C++ compilers for AIX, IBM i and mainframe, but they've been converging to LLVM. I believe the pre-LLVM versions share a common backend with some of their other language compilers (COBOL, PL/I, PL/X, PL.8, etc), ultimately going back to work of their Toronto and Yorktown labs starting in the 1980s. More recently they've started replacing their C/C++ frontends with LLVMs, while keeping their own backend; and even more recently swapping out their backend for LLVM's too.
Good point. I completely forgot IBM. And I even was a trainee there, when mainframes where a big thing, PCs an exception and nobody including myself had heard about AIX (although technically it was a year old).
Probably not qualifies as "wide use" but embedded compilers like SDCC still matters. Yes, 8-bits are giving way to ARM, but there will be a few more millennia before they are out.
Clang, GCC and MSVC are the big ones, the rest are more or less niche compilers - with Clang and GCC only differing in small details.
(one could argue that MSVC is slowly becoming a niche compiler too - it feels like it's not as important anymore as it was 10..15 years ago, maybe because a lot of new C/C++ programmers seem to start on Linux, not Windows - that's at least the 'general vibe' I'm getting)
True of course, but then MSVC only matters for building Windows and Xbox games (and at least on Windows I would also give Clang a try since it typically optimizes better than MSVC).
Currently, zig cc is the Clang frontend which is linked into the Zig compiler (most things in that blog post are about differences between the Zig toolchain and a typical Clang toolchain for cross-compilation, and how Zig invokes the Clang frontend).
I'm not sure what the current plan is for C compilation after the LLVM divorce and after Clang will be moved into a Zig package (e.g. I remember talk that arocc [1] is going to be integrated into the Zig compiler, but not sure if that's still planned, or if C compilation will also be delegated to the new Clang package along with C++ and ObjC compilation).
The maintainer of oksh has an interesting comparison[1] between tcc and cproc as it comes to the performance of the generated code on OpenBSD. To be clear, cproc delivers. But tcc beats it, usually significantly, for reasons I can’t even begin to see how to investigate. It actually beats cparser/libfirm in most cases, which just makes no sense. (I ran the benchmarks myself on Linux some months ago; with the versions given in the original post, they reproduce.)
Right?.. There’s a reason I decided to spend the couple of hours it took to get libfirm to compile. Then again, it’s a shell benchmark, most of it is bound to be syscalls and (nonfancy) parsing, so the space for an optimizing compiler to make a difference is bound to be fairly limited. All the compilers in the test are within 2× of the best one, and CompCert isn’t exactly a speed demon either. I’d love to dig into this, but there are so many layers of stuff I don’t really know where to start.
I tested with tcc, cparser and my own slimcc, the benchmark showed multiple process with htop, so there are some dynamic cpu scaling randomness going on. I saw larger run-to-run differences with the same binary, than with comparing cherry-picked best-run of each, so probably not the best benchmark.
Not really working in the area and did not research now, but I can come up with:
* gcc
* clang
* Microsoft probably has their own implementation
* Intel probably still has their own implementation
* ?
Edit: OpenVMS maybe, but not sure whether that qualifies for in wider use
Edit2: ARM of course