1. 17
  1.  

  2. 5

    LLVM 13 includes a new pass manager that significantly improves compile times in Rust: https://twitter.com/ryan_levick/status/1443202538099073027?s=21

    1. 3

      to be clear: this is not a new pass manager, just enabling the “new” pass manager by default. The “new” pass manager has been in llvm for years, but it is still difficult to find good documentation on how to use it. Hopefully, things will improve now

    2. 3

      I guess it’s a good indication of the maturity of LLVM that I am no longer excited about new releases. Back in the 2.x days, I was usually working with trunk because every few weeks there would be an exciting new feature. Now, I’m looking forward to the opaque pointer work being finished but aside from new C++ features in clang I don’t notice much difference between releases.

      I’ve never used GCC as anything other than a compiler (the GPL made embedding it in other stuff undesirable) but I also remember being excited about each new GCC release in the 3.x series. Now GCC’s in pretty much the same position for me: a new release may have new C++ features that I want to use but aside from that it’s pretty boring.

      Being boring is probably what infrastructure projects should aspire to, but it still makes me a bit sad.

      1. 2

        Is it? This page says “These are in-progress notes for the upcoming LLVM 13 release”, and many of the sections are blank or placeholders.

        1. 3

          It is. Here is llvm-announce email. LLVM historically has been lazy about writing release notes and often filled details after the fact.

        2. 1

          Here are the corresponding Clang 13 release notes. Also frustratingly incomplete, but I’m excited about this feature that was mentioned here a few months ago:

          Guaranteed tail calls are now supported with statement attributes [[clang::musttail]] in C++ and __attribute__((musttail)) in C. The attribute is applied to a return statement (not a function declaration), and an error is emitted if a tail call cannot be guaranteed, for example if the function signatures of caller and callee are not compatible. Guaranteed tail calls enable a class of algorithms that would otherwise use an arbitrary amount of stack space.

          My experimental “Tails” Forthlike interpreter doesn’t work reliably without this; Clang 12 would sometimes decide to generate non-tail-recursive code, for reasons unknown.

          Update: also libc++ release notes.

          1. 1

            Last time I looked, [[clang::musttail]] was quite buggy. It requires that the callee has the same set of argument types as the caller. This might be fine for your use case but we wanted to use it in an always_inline function and clang rejected it because the always-inline function’s signature did not match the callee (though the caller did, after inlining). This is quite unfortunate because it means that cleanly refactored code can’t use the attribute.

            1. 1

              I think my code will be ok with that. Sounds like whoever implemented this was focused on tail recursion and didn’t think of other cases.