LLVM 12 | Hacker News Reader

LLVM 12

releases.llvm.org

160 pointssamber34 comments

Wow, these release notes are completely useless. Here are some actual highlights of this release:

* LLVM no longer assumes forward progress by default. This means it no longer miscompiles infinite loops in non-C++ programming languages.

* LLVM now tracks applicability scopes for scoped noalias metadata. This means LLVM no longer miscompiles code for languages with high-quality aliasing information.

* Dead store elimination now uses MemorySSA, and can eliminate dead stores across basic blocks.

People rarely seem to add release notes for their changes and I don't think anyone goes back at the end of the release cycle and picks out the highlights.

For C++ features you also might be better off looking at cppreference.com [0].

[0]: https://en.cppreference.com/w/cpp/compiler_support

I thought I was the only one with a git repo full of comments like "now with less bugs!"

"Now with different bugs!"

Ser Davos has some thoughts about your comment.

http://gph.is/2vGAqYf

Davos learned that from Stannis.

https://www.youtube.com/watch?v=G0zNWswcqMg

Except this is about llvm and not clang. C++ features don't come into play with llvm since it's the middle step between the high-level compilation of the language and the writing actual machine code for the target architecture.

> Dead store elimination now uses MemorySSA, and can eliminate dead stores across basic blocks.

I thought it wasn't enabled by default in 12? I recall this being said at some point.

That said, I do appreciate this change making it into Rust, as it very visibly improves how it handles moving big structs around.

The change you have in mind is MemorySSA-based memcpy optimization, which is indeed not enabled in LLVM 12 (but is enabled in Rust).

...oh, yeah, I saw "now uses MemorySSA" and immediately thought of the memcpy optimization pass, without carefully reading the entire comment - my bad.

> This means LLVM no longer miscompiles code for languages with high-quality aliasing information.

This affects Rust, for instance, and might net 0-5% better run-time performance: https://github.com/rust-lang/rust/issues/54878#issuecomment-...

In general I would be very curious to know more about the bugs, etc in LLVM which would benefit Rust. I'm of the impression that there are many because LLVM is so over-fitted to the C++ ecosystem, but I don't know much about them in particular.

If you're looking for someone to ask, the expert is nikic, author of the grandparent to your comment. They have worked on many of these specific improvements in LLVM, from which Rust has benefited.

You're saying the person complaining about the release notes is one of the people who wrote the release notes? :-D

The `A-LLVM` issue label is probably a good starting point.

https://github.com/rust-lang/rust/labels/A-LLVM

* LLVMBuild is removed. This means most of the building works are handled by CMake now

I don’t read LLVM release notes very often and had a possibly stupid question:

> Changes to the ARM Backend

> During this release …

And that’s all it says. Is this just a placeholder that wasn’t deleted? Or an indication that there were changes but they are too minor/technical to usefully detail? There are many empty sections but only a handful have the “during this release...” boilerplate.

Yeah, the whole page reads like a draft

Yes, I suspect the release notes are still being worked on. Or at least, I never noticed these sort of statements in the past.

> Note that if you are reading this file from a Git checkout or the main LLVM web page, this document applies to the next release, not the current one. To see the release notes for a specific release, please see the releases page.

That seems to indicate that it’s a work in progress and someone forgot to do a cleanup process for things that didn’t change.

It does look like they missed the "write release notes" part of the release playbook. ...does LLVM have a release playbook? Is it public?

As m68k support has been merged, I am looking forward to the next major LLVM release.

M68k LLVM maintainer here: I'm also excited about it :-) I'll try my best to write a proper release note.

I haven't been able to find this so I ask: Does LLVM have an assembler? Not the llvm bytecode (llvm-as), but architecture-specific code (like gas, the gnu assembler).

Yes. "clang Foo.S" will use a built-in assembler. "llvm-mc" is another command line interface to that same assembler library.

I like their no-frills home page better. (Reminds me of Slackware's.)

Picolisp supports IR from llvm12 and llvm13-nightly works too.

How does perf compare against GCC?

How well can it target nvidia GPUs?

Does machine code analyzer support in order hardware yet ?

CUDA compilers are a fork of LLVM.

They use LLVM, but without the Clang part. (even available to 3rd-party apps as NVVM, which currently takes in LLVM 7 byte code)

Upstream Clang supports compiling CUDA code however.

lol. just lol. first thought when I read that

1. Phoronix regularly releases benchmarks. You should look at them. At the end of the day it’s all workload-dependent and they trade off the performance crown.

2. Do you mean this [1]? If so then for a while it seems.

3. I don’t understand the question. I can’t find anything called a “machine code analyzer” or how the code analyzer/or any sanitizers relate to in-order vs out-of-order hardware as a class. The former works at source level. The latter is a mixture of library support code and codegen instrumentation and I’m not aware of anything specifically that relies on the execution mode of a CPU (I would imagine RAM constraints are the bigger issue).

[1] https://www.hahnjo.de/blog/2018/10/08/clang-7.0-openmp-offlo...

llvm-mca

LLVM has a project called mca which reused the machine description files used for instruction scheduling to model the throughout of a basic block in steady state.

Sounds cool, is cool - word of warning: it can be a little optimistic sometimes.

Reply on news.ycombinator.com