LLVM 13.0
lwn.net
lwn.net
I talked more about some performance motivation for this feature here: https://blog.reverberate.org/2021/04/21/musttail-efficient-i...
https://reviews.llvm.org/D107872 makes me doubt.
In addition to the bug you mentioned, there are a few architectures where musttail is not supported supported. The POWER backend (big endian or pre-POWER10) and ARM backend (32-bit only) will throw errors for musttail in the backend.
In the long-term though, I see this being a solid foundation on which to build. x86/x64/ARM64/POWER10 all support it. All the architectures seem to be going in a direction where this is possible to guarantee. Hopefully the bugs will get ironed out over time. Thanks for your bugfix on this!
Also unfortunately the inline keyword doesn't really do much except make the author feel happy they thought the compiler they told it to inline that function.
int
foo(int a, int b)
{
...
}
__attribute__((unused))
__attribute__((format (printf 1, 2)))
static inline char *
sformat(const char *fmt, ...)
{
...
}
K&R and Linux styles are similar:
int foo(int a, int b)
{
...
}
Note: All these styles normally place braces on the same line as control flow statements. Function definitions are treated differently for what I understand in hindsight are good (if possibly serendipitous) reasons.
C++ complicates things with methods, template, etc, so I'm not sure how well the above styles fit C++. In what little C++ I've written one of my first gripes was with difficulties controlling linkage, period.
Hopefully it's just a bug in those backends, and not that the C++ standards committee ratified something that's impossible to support on certain architectures.
I believe the backend issues mostly center around DSOs. I am hoping that the dso_local attribute can help out here: https://llvm.org/docs/LangRef.html#runtime-preemption-specif...
If musttail only works for functions within the same DSO, that seems sufficient.
EDIT: The new pass manager which improved the compile times is not scheduled to be enabled until Rust 1.57 (the release after the next one).
So you can already use it to easily compile and cross-compile code (Zig, but also C and C++) to many targets including WebAssembly and Apple Silicon, using LLVM 13.
https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...
HN discussion:
https://news.ycombinator.com/item?id=27872596
previous discussion:
There are some follow-up issues related to zig cc which are still open:
- ...
- support compiling and linking c++ code
rayga@DESKTOP-88A51E5 MINGW64 ~/Projects/tmp/zig-cc-test
$ zig version
0.9.0-dev.959+f011f1393
rayga@DESKTOP-88A51E5 MINGW64 ~/Projects/tmp/zig-cc-test
$ zig cc test.cpp
test.cpp:1:10: fatal error: 'iostream' file not found
#include <iostream>
^~~~~~~~~~
1 error generated.
rayga@DESKTOP-88A51E5 MINGW64 ~/Projects/tmp/zig-cc-test
$ clang test.cpp
rayga@DESKTOP-88A51E5 MINGW64 ~/Projects/tmp/zig-cc-test
$Indeed it also right under "zig cc" in the output for "zig --help" too, if that wasn't clear enough:
$ zig --help
Usage: zig [command] [options]
Commands:
cc Use Zig as a drop-in C compiler
c++ Use Zig as a drop-in C++ compilerhttps://github.com/ziglang/zig/issues/4786
It was closed in March of 2020.
> zig c++ is equivalent to zig cc with an added -lc++ parameter, but I made a separate heading here because I realized that some people are not aware that Zig supports compiling C++ code and providing libc++ too!
You can also mix Zig code and C++ like this:
zig build-exe foo.zig bar.cpp -lc++ -lcFrom my point of view, for Apple, their use of C++, C++17 is good enough.
Metal uses a C++14 dialect as shading language, IO and DriverKit an embedded friendly subset, for everything else there is Objective-C and Swift.
Google seems to have been put off by losing the ABI vote and changed focus into Abseil instead, and have their own Draconian style guide anyway.
And are increasingly adopting Rust as well.
Intel, ARM, IBM, Sony, Nintendo will have to jump in.
By the way, concepts were mostly implemented by a single guy!
Intel and IBM have recently announced their own proprietary LLVM-based compilers, but they seem more interested in backend work to make their own CPU's look good [1] than spending resources on frontend work. I guess that applies to ARM as well.
Sony and Nintendo are, I guess, mostly satisfied? They just want a decently good compiler and toolchain ecosystem, but for games most performance comes from the GPU anyway, chasing low-single-digit performance increases for CPU code doesn't seems like a super good investment opportunity for a game console company.
There are a couple of talks from them at some LLVM summits.
> Commercial use began when Dell and IBM, followed by Hewlett-Packard, started offering Linux support to escape Microsoft's monopoly in the desktop operating system market
-- Wikipedia
If we reach the point where redhat pulls the cash out from GNU then there's a lot of infrastructure that will be lost. I find it alarming that no one ever seems to mention that.
If your company is making use of Linux, GCC, OpenSSL and so forth, they should be setting aside some engineering resources to contribute to those projects, especially if they aren't paying a corporate vendor like RH, SUSE, or Canonical to do it on their behalf.
Naturally, the "tragedy of the commons" is that everyone wants to take advantage of free software while contributing back as little as possible, usually while simultaneously complaining or handwringing about those that are actually contributing.
Why is it that this conversation has turned from Apple and Google, with a combined market cap over 4 trillion dollars pulling their resources from these foundational projects, to handwringing that Red Hat, with a 125x smaller valuation might pull their resources from GNU, something there is no indication of happening? Surely the focus ought to be in the other direction...
IIRC Redhat withdrew funding from FSF after they decided to put RMS back on the board. But AFAICS they haven't reduced funding for developing GNU software.
Lets put it this way; RH doesn't contribute to GCC out of the goodness of their hearts, but due to GCC being a critical component of the Linux distro (RHEL) and other similar product support offerings they make their money from. If they drop GCC development, it'll be because something else has replaced GCC and they figure it's better to concentrate their efforts there, or because their business as a whole is going down the drain. For the time being I don't really see either option as particularly likely.
This highlights an important difference between GCC and LLVM that many fans of the latter seem to miss: LLVM is first a bunch of compiler components that Apple and Google use for their own needs and a C/C++/etc compiler for you and me second and only as long as it flows naturally from the first. While GCC is a C/C++/etc compiler, that's the end-goal.
The root of the problem is that very few people find it "FUN" to implement C++ compilers on their free time, so these open source projects live from companies for contributions.
GCC existed and thrived long before companies started putting money into it. It would clearly suffer if, e.g., Red-Hat withdrew its support, but not nearly as LLVM would in the same situation.
The culture, history and governance of the two projects are very different and they do matter.
LLVM has the support of most compiler research groups across the globe, so in contrast with GCC, there is a steady flow of "LLVM PhD"s coming out of academia in need of a job, and "LLVM PhD"s becoming professors and continuing doing research with LLVM, and then a large set of CS students doing all kind of works with those professors on LLVM, which creates a steady flow of "BSc"/"MSc" LLVM professionals.
On top of that, many technology companies have built their whole platforms on top of LLVM.
GCC doesn't really have that. If Red-Hat and other private companies withdraw support, there are really few people familiar enough with GCC to keep it afloat, few people interested in learning and contributing because that won't land them industry jobs, etc.
That is irrelevant, as most of those companies are keeping their modifications to LLVM closed-source. They are not at all interested in fostering a healthy open-source ecosystem around LLVM.
> GCC doesn't really have that.
This is just wrong. Just as a single example, the first ever C++ concepts implementation was written for GCC by Andrew Sutton, a University professor and co-author with Bjarne of the concepts proposal. LLVM's implementation came years later, and it's not as stable or complete to this day.
> If Red-Hat and other private companies withdraw support, there are really few people familiar enough with GCC to keep it afloat, few people interested in learning and contributing because that won't land them industry jobs, etc.
Again, no. There is nothing in the 30+-years long history of GCC that suggests that this would happen.
AMD, Intel, ARM, ... they all have proprietary toolchains built on LLVM, and send and merge multiple diffs to LLVM upstream, every day.
> GCC doesn't really have that. This is just wrong. Just as a single example,
If that's your main example, you are in for a ride. Since asutton branch is over 15 years old almost at this point, and it was by design that no work should happen in LLVM until concepts make it into the standard.
I can give you a dozen examples, from constexpr, metaclasses, coroutines, modules, etc. where things made it much earlier into LLVM than GCC.
> Again, no. There is nothing in the 30+-years long history of GCC that suggests that this would happen.
From 2005 to 2014 GCC development severely stagnated, being much slower than clang, having horrible error messages when compared to clang, etc. It was not until after 2016 where some open source companies, like redhat, started pouring more money into GCC that this started to change. The moment these companies are out, the same thing will happen.
Nice strawman, what does this have to do with anything that I wrote?
You went on and on about how there's heaps of "LLVM PhDs" (whatever that might mean) coming out of academia, so I gave you an example of someone working in academia who developed and contributed a key C++ feature to GCC.
> I can give you a dozen examples, from constexpr, metaclasses, coroutines, modules, etc. where things made it much earlier into LLVM than GCC.
That's not my experience, and I have been using GCC and Clang daily on modern C++ codebases targeting the latest standard for the last 10 years.
> From 2005 to 2014 GCC development severely stagnated, being much slower than clang, having horrible error messages when compared to clang, etc.
Yes, GCC's diagnostics have been trailing Clang's, though they have mostly caught up in the last few versions. But "much slower than clang" is flat out wrong, unless you mean compile-time performance. GCC has for years consistently produced more optimised code than Clang's, and it only in the last couple of years that the two compilers are essentially on performance parity.
> AMD, Intel, ARM, ... they all have proprietary toolchains built on LLVM, and send and merge multiple diffs to LLVM upstream, every day.
I seriously doubt that AMD/Intel/ARM engineers are doing substantial work on C++20 features, but I'd be happy to be proven wrong :)
Google has not "backed out".
E.g. look at this topic's discussion thread. The current top comment is about [[clang::musttail]]; the implementor of that attribute works for Google. The current second top comment is about the Rust compilation wins from the switch to the New Pass Manager; the NPM was primarily implemented by (and turned on as the default pass manager upstream) by people who work for Google. Google is actually growing our investment in people contributing to core Clang/LLVM.
Source: I am a manager for C++ toolchains (those that target production, Chrome, ChromeOS) at Google.
Which you pretty much confirmed by giving examples completely unrelated to ISO.
How is that migration to C++20 modules support going?
E.g. for standard concepts in libc++:
std::derived_from (D74292) std::convertible_to (D77961) Arithmetic concepts (D88131) std::move_constructible (D96230) std::copy_constructible (D96232) std::invocable (D96235) std::regular_invocable (D96235) etc.
Google is _big_ and C++ is used for many projects that build with disparate toolchains (even if they are all based on Clang/LLVM); each project can have different needs to adopt parts of C++20 sooner than the others, and different costs for doing so. Moving from Clang modules to C++ standard modules is an effort that, for some of our projects, lives at the nexus of "Are Standard Modules sufficiently done upstream to be able to replace our use of Clang modules?" and "What is the cost of doing that?" and "What is the benefit of making that switch?" For other projects, adopting standard modules is a more straightforward calculus.
I don't have a point with this other that it's surprising (for end-users like me). Also, I'm not sure how GCC compares.
Not favorably. Both projects have massive "backlogs," by naive metrics.
Maintainers for both are in a double bind: people get mad when you close their years-old issues because they can't be reproduced anymore, and people give you grief for not closing issues.
In what concerns throwing out C++/CX out of the window and tell us to go back to the days of ATL 3.0, and wait for the day Herb's metaclasses arrive into the standard, not so much.
https://releases.llvm.org/11.0.0/docs/tutorial/MyFirstLangua...