AVR is an official backend now. Rust has also recently added support for AVR.
One more backend I'd like to see is the Espressif (ESP32 etc.) one. They've trying to upstream the support, but it seems that the lack of reviewers from the part of LLVM is slowing down the process...?
I was under the impression from reading the patch comments [1] that it was more of an issue with them not having an open copy of their ISA documentation (which then is causing a lack of possible reviewers)
I've been waiting for Espressif being upstreamed myself. I only arrived in the ecosystem about two months ago, but it has been absolutely amazing to see the team work. And by that I mean the esp-rs group, but also the rust-embedded working group in general.
They congregate on matrix and most "remote" companies could probably learn a bit or two about remote development from them.
A few items from the release notes that caught my attention:
* The debug information now has a feature which lets your debugger recover the value of an optimized-out value in certain (common) circumstances. I wish gdb and lldb pick on up this quickly and that it doesn't need you to specify anything explicitly.
* If you're doing JITing with LLVM, you can now run your code's static initializations (which apparently you couldn't before? :-O )
* Lots of RISC-V-related work (features, optimization improvements and bug fixes).
* Nothing new for PTX (the CUDA IR which you can use LLVM to generate).
> The debug information now has a feature which lets your debugger recover the value of an optimized-out value in certain (common) circumstances. I wish gdb and lldb pick on up this quickly and that it doesn't need you to specify anything explicitly.
It drives me nuts when I compile code with "-ggdb -gdwarf-4 -O0" and gdb still reports some symbols as "optimized away". I hope the bullet point above refers to this.
It's DWARF-5 only: variable values can be expressed in terms of a parameters value on entry to the function. Depending on the circumstances, that value can be recovered from further up the stack frame.
(Ninja edit: although tuning for GDB might coax LLVM to emit the pre-standardised form, without DWARF-5).
When I have to debug a production crash (compiled with -O3), that's usually what I do today. Basically, the value can be derived from something that's static/global, eventually. Now that I think about it though, I'm kind of surprised gdb hasn't done that for me historically, but maybe the debug info isn't detailed enough and I can do it just because I can read the actual source.
I don't recall. Sometimes doing a full rebuilt takes more a while, so my process goes something like this:
1) build with "-O0 -ggdb"
2) In a debug session, notice that a variable I want to inspect has supposedly been optimized away. Get extremely frustrated.
3) Rebuild with every debug-friendly flag I can conceive of "-O0 -ggdb -fno-inline -gdwarf-4 -fno-omit-frame-pointer ..."
4) IIRC, step 3 usually (but not always?) addresses the issue.
But long story short, I don't think I've ever pinned down the minimal requirements for avoiding the issue. Usually when I encounter this, I have bigger issues to deal with.
What difference does -ggdb make vs -g? I see it does extra 'tuning' of the debug output for GDB [1], but it's unclear what effect that might actually have.
Our internal mono-repo with about 11000 C++ compilation units took about the same time with clang-11 compared to clang-10.
I used the Ubuntu 20.04 packages from apt.llvm.org for testing.
I don't have a link on me, but I recall that Rust reported some improved compilation time from upgrading to LLVM 11 (which is the default for 1.47, released last week).
Kind of interesting, I was looking at the wikipedia page for LLVM and noticed Delphi was listed, and sure enough the more modern compilers for Delphi are LLVM based[0]. I remember discussing with people just a few days ago here on HN about how the Delphi compiler used to be blazing fast due to being written in Assembly[1]. It's kind of nice to see that others are taking full advantage of LLVM at an official capacity at least, making it much more tried and tested, not that it wasn't already tried and tested before. I think Rust / Swift as well don't hurt. It would be nice to see Kotlin Native taken a lot more seriously by JetBrains on the other hand.
The thing that caught my eye in the release notes is the blurb about Zig:
Zig is a general-purpose programming language and toolchain for maintaining robust, optimal, and reusable software. In addition to supporting LLVM as an optional backend, Zig links Clang and LLD to provide an out-of-the-box cross compilation experience, not only for Zig code but for C and C++ code as well. Using a sophisticated caching system, Zig lazily builds from source compiler-rt, mingw-w64, musl, glibc, libcxx, libcxxabi, and libunwind for the selected target - a “batteries included” drop-in for GCC/Clang that works the same on every platform.
What specifically, that they mention Zig or that you learned of Zig or that Zig has a lazy build system or ???
The thing I really find interesting about Zig is the compile time function evaluation [1] and how it can stand-in for macros, code generation, precomputing values, etc. I think of CTFE as a continuation that comes baked into the binary from an earlier point in time, T-days_ago.
As for this release, I am stoked to see Flang making progress. I am excited about Fortran in the browser.
The interesting thing of note is that Zig is in the process of creating their own backend, but I don't see them dropping LLVM any time soon. An alternate backend is a great way to find bugs in codegen.
Zig's comptime is surprisingly powerful and does not suffer C++ template problem when an error message at the instantiation site is extremely unhelpful. And Zig managed it without constrains or traits just via bunch of useful compile-time operations on types. Still I do not see how one can have, for example, a struct field or enum case available only at certain compile-time condition like OS version.
You can put together an `std.builtin.TypeInfo` structure describing the type (eg. by using `@typeInfo` on an existing type and editing the result, adding something under `.Struct.fields`); then use `@Type` to 'unreflect' it back into a real type.
Zig's home-grown backend is strictly for super-quick turnaround compile and link during development. For optimized release builds, they'll depend on LLVM forever.
I think that is a lovely solution for a couple reasons. First it allows the project to optimize for its goals (dev latency), this allows the team to have more local control and autonomy.
Second, it puts _less_ pressure on LLVM to have both a low latency version and a highly optimized version. If the LLVM IR could be more of a common format, I think it would provide a medium for tools to compose better. Eventually we will get there, compiler gods willing. I think LLVM should be the place for the massive-engineering-effort optimization passes.
Lastly, it provides for differential testing of both backends, this makes Zig's homegrown one AND LLVM better.
Random question, but you’re the first commenter who mentioned flang, so I am hoping you know the answer: is Flang doing its own alias management to enable Fortran’s optimizations on arrays, or did LLVM finally regain usable alias attributes in the backend?
That’s interesting. Is it personal familiarity with the language that drives your desire or is some features of the language that you find lacking in alternative languages already in the browser space?
I'm probably biased but comptime doesn't seem as elegant as the mechanism D provides for doing CTFE (i.e. I prefer a separation of quasi-template parameters)
Can you eg. generate a struct with fields based on an existing struct or on a comptime array in D? Can you receive a structure literal of anonymous type and iterate over it at compile time? (curious bc. these were a few things I found straightforward in Zig, and in C++ the main proposals involve tons of new metaclasses and reflection features for)
D doesn't go the C++ route, the way code like this works is via generating new code (in text) at compile time which the compiler then compiles (duh) and replaces the mixin statement within.
Here's an annotated example of these features in use
That is beautiful. I wish C++ had something like that... Perhaps in addition to its current template system. Having a separate build pass to generate files is annoying.
That looks a lot more complicated than D's simple "output text that gets fed back into the compiler". But admittedly I only quickly jumped around the video. Hopefully it works well, though.
That's what I meant by doesn't go the C++ way. The standards committee over complicate everything (concepts still haven't landed yet for example, D has
D a better more flexible system 15 years ago I think)
Already available as experimental on VC++, and approved as part of C++20.
As proven by every failed attempt to replace languages with industry standards, plenty of companies do care about ISO and ECMA language standards.
D is a nice language, but spends too much time focusing on the language and its cool metaprograming capabilities, without focus on the ecosystem.
Slowly Java, C#, C++ will have the features that made D unique, with the plus side of 20 - 40 years of libraries, IDE support and industry certifications.
While I agree that D is a 'treasure' (full of good ideas that should be copied more often by other languages) I don't understand why you think that D's way is better than Zig here..
What exactly do you prefer?
It's personal preference, but if a parameter is well and truly compile time I think it should be separate from the others (it certainly makes introspection "easier")
I've been building a similar toolchain which uses the same version of clang / libc++ / etc everywhere for my own software and things are so much more sane than trying to use GCC/libstdc++ on Linux, Clang/libc++ on macOS and MSVC on Windows which all have various behavior and performance divergence & pitfalls.
CI still tests GCC and MSVC (except that MSVC of course has been ICE'ing on my project for the last six months), but all the releases are built with clang and my sleep quality has never been better :-)
I submitted the announcement email because it links to release notes from all the projects (i.e. Clang, LLD, Flang, etc.) and not just the main LLVM ones.
(Also it seems the version number changed from 11.0.0 to 11.0?)
That makes sense, but lists of links don't make good HN submissions, since there isn't much to discuss beyond the lowest common denominator of the items on the list. It's best to pick the most interesting element from the list and submit that—especially since HN is itself a list of links already. https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...
(yes, we always do that with x.0.0 version numbers)
One more backend I'd like to see is the Espressif (ESP32 etc.) one. They've trying to upstream the support, but it seems that the lack of reviewers from the part of LLVM is slowing down the process...?