LLVM 11.0 | Hacker News Reader

LLVM 11.0

releases.llvm.org

223 pointszmodem71 comments

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)

[1] https://reviews.llvm.org/D64830

I stand corrected.

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.

The m68k (68000 family) backend effort is trying to get upstreamed, too.

The progress is covered here[0] somewhat.

https://secure.m68k.info/

> The macros enable users to write C/C++ Vector Length Agnostic (VLA) loops,

What a great idea to use VLA to mean something else than it does for ISO C99.

Oh, good catch that's a big oof. I wonder if they were just unaware of this feature or what...

I am excited for this feature though, naming aside.

Is this sarcasm? I can’t tell.

Yes.

Relevant page: https://releases.llvm.org/11.0.0/tools/clang/docs/ReleaseNot...

Why not vector size agnostic?

Because VLA already means “variable length array”, which is confusing.

They're saying why not use "vector size agnostic" because that would be VSA instead of VLA, hopefully avoiding confusion.

llvm is a bloated piece of ... mess ... built on a bloated language (C++) ...

Avoid at all cost.

For more details, see the specific release notes:

https://releases.llvm.org/11.0.0/docs/ReleaseNotes.html https://releases.llvm.org/11.0.0/tools/clang/docs/ReleaseNot... https://releases.llvm.org/11.0.0/tools/clang/tools/extra/doc... https://releases.llvm.org/11.0.0/tools/flang/docs/ReleaseNot... https://releases.llvm.org/11.0.0/tools/lld/docs/ReleaseNotes... https://releases.llvm.org/11.0.0/tools/polly/docs/ReleaseNot... https://releases.llvm.org/11.0.0/projects/libcxx/docs/Releas...

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.

I can't say I've ever seen that (I still use dwarf 3 however). Is there a certain pattern to it?

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.

Does "-g" and no optimization flags not work?

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.

[1]: https://clang.llvm.org/docs/UsersManual.html#controlling-deb...

Are there any benchmarks that show compilation times using LLVM 11 versus older versions for representative projects?

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).

IIRC llvm 11 addressed a regression in compilation times.

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.

Julia devs are posting things like:

    julia-master with llvm10:
    % julia-master --project=. --startup-file=no -e '@time using Plots'
      4.028043 seconds (6.51 M allocations: 470.491 MiB, 4.07% gc time, 16.62% compilation time)
    llvm11:
    % julia-master --project=. --startup-file=no -e '@time using Plots'
      3.392166 seconds (5.97 M allocations: 431.075 MiB, 3.46% gc time, 17.22% compilation time)

So it looks promising that the startup + compilation time is improved.

I wonder if cutting out a few million allocations might help

Julia is particularly sensitive to LLVM compile times. LLVM 11 did improve those over LLVM 10 (which had noticeable regressions versus LLVM 9). As an example see https://github.com/JuliaLang/julia/issues/37915#issuecomment...

We fixed a method taking 13% of Linux kernel compiles in llvm-11.

I am interested to read the details behind this.

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.

[0]: http://docwiki.embarcadero.com/RADStudio/Sydney/en/LLVM-base...

[1]: https://news.ycombinator.com/item?id=24735969

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.

Yep, that is a highly significant feature!

https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...

I vouched for your comment but it looks like you may be shadow banned. Just an FYI -- you might want to email the mods, they're quite nice people.

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.

[1] https://andrewkelley.me/post/zig-programming-language-blurs-...

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)

Yes to all points.

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

https://run.dlang.io/is/2b5zgC

Brilliant.

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.

It does, via constexpr, which just got more expressive in C++20, and is the basis for the ongoing compile time reflection work on C++23.

Code injection might eventually come later via Microsoft's ongoing research in C++ metaclasses.

"Dynamic Polymorphism with Metaclasses and Code Injection"

https://www.youtube.com/watch?v=8c6BAQcYF_E

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.

True, but a programming language is more than just syntax and for better or worse, the ecosystem is what matters.

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)

And no ecosystem to speak off, while that standards committee is making sure that GPGPU programming is the next killer application for C++.

How are modules coming along then?

C++ has succeeded despite the committee not because of it.

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.

Cool! Nim is related here, where instead of text manipulation you're doing AST manipulation with quasi-quoting (like in many lisps), eg. https://nim-lang.org/docs/tut3.html#introduction-building-yo....

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")

Aside, there no reason that this comment should be downvoted.

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.

Splendid! This is much more flexible than various static if aproaches like in D or modern C++.

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?

Perf isn't a high priority for me, more about getting Fortran into the browser. I don't have insights into the aliasing.

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?

Another option may be wanting to port existing Fortran libraries to web.

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.

Thanks for sponsoring Zig!

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 recall zig being mentioned in the last ... I don’t know how many releases.

Are there any estimates within the LLVM community when c++20 feature complete might be reached?

Anyone was able to use test Zig in Windows? last time i tried it, it compiled but i was not able to print a hello world. Thank you.

It's been working great on windows for me for the last year or so. When did you last try it?

Release notes: https://releases.llvm.org/11.0.0/docs/ReleaseNotes.html

Changed to that from https://lists.llvm.org/pipermail/llvm-announce/2020-October/.... Thanks!

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)

Reply on news.ycombinator.com