LLVM 8.0.0 Release | Hacker News Reader

LLVM 8.0.0 Release

lists.llvm.org

302 pointssamber49 comments

I've been wanting to test out the LLVM IR to WebAssembly compilation, but I've been too lazy (or impatient) to compile LLVM from source. Nice to see that it's now enabled by default!

There truly is nothing to it. I just built it for the first time on this fresh install of Ubuntu. You can just copy and paste the lines from the getting started page.[1] Here's my .bash_history:

  $ git clone https://github.com/llvm/llvm-project.git
  $ cd llvm-project
  $ mkdir build && cd build
  $ cmake -DLLVM_ENABLE_PROJECTS=clang -DCMAKE_BUILD_TYPE=Release -G "Unix Makefiles" ../llvm
  $ make -j4

Took < 40 min on an old laptop.

[1] https://clang.llvm.org/get_started.html

It doesn't matter much when you build only once, but more people need to be aware of Ninja for builds. Both cmake and meson can target it, and it is much faster for incremental builds.

I never understand this. Surely 'make' itself uses an almost irrelevantly low amount of CPU compared to compiling?

That being said: have used Ninja with Cmake. Damn fast.

It's not so much how much CPU each takes up, but that 'make' will waste some time recompiling stuff that doesn't need to be recompiled. Ninja is better about reusing stuff compiled the first time to make the second compilation faster but still accurate.

Isn't the point of `make` that it doesn't build stuff that doesn't need to be rebuilt? Am I missing something?

I guess make and ninjia use different algorithm to compute the targets that does not beed to rebuild.

The problem is with how make checks which files have changed and the related I/O latency, plus the fact that pretty much everybody uses recursive make. The overhead of recursive make initialization plus the forced serialisation of builds is the main cause of slow make.

Consider the Linux kernel as a contrast, which doesn't suffer from slow make because a lot of investment was made into a non-recursive make system.

The fact that makefile generators like CMake tend to generate recursive makefiles is a shame.

Last time I tried on a not super new laptop, it couldn't link. It really needs 8GB of RAM last time I tried.

Something was wrong with your setup. I've built clang in the past on a VM with only 3GB physical + 3GB of virtual RAM/swap allocated.

Recently? It was a 4GB laptop that ran out of memory while linking back in Oct '18.

Does this mean wasm is effectively just another ISA to compile to and emscripten is no longer needed?

If you need really small functions, yes. emscripten is providing all the libc functions, WASM loading code and binding generators. You will probably need some of that when porting existing libraries or applications to the web!

Well, you generally need a libc when compiling for any platform, so that shouldn't be too special?

You don't inherently need a libc for wasm. That is, libc is usually the API for the platform; wasm doesn't have such a thing really. Your wasm module says "hey, these are the functions I expose, and these are the functions that I am planning to call from the environment" and it's the host's job to wire that up properly. In the browser, that means when you instantiate a wasm module, you need to provide all the required functions, and then you can call the exposed functions from JS. Outside the browser, what things you can call and will be called is defined by the host.

A libc can be useful inside of wasm for existing C or C++ code (or whatever) that is built for another platform, so that you can more easily compile to wasm as well. But it's an option, not required.

Well, I meant that if you want to cross compile general code, you might want malloc, printf etc...

I'm not sure the primary appeal of wasm is treating it as a low level target (even if that is possible and sometimes useful).

You can get that stuff without a libc, if you’re not literally compiling C or C++. If you are, you’re right, though.

You don't necessarily need it. You could have some math focused code you want to call from JS.

That is a good question, but as I understand it (from reading only) emscripten does a few other things, such as convert opengl calls to webgl, as well as use special integrated versions of SDL and GLFW so that native programs that use those libraries can be compiled directly.

Both of those would include input and I think audio is dealt with in a similar way.

It's a bit more complex than that. emscripten tries to provide a full environment; it adds a runtime with features like a libc. It also produces some HTML and JavaScript to load up the wasm, etc. The new wasm target gives you none of that. This means smaller binaries for some things, but it's harder to get existing desktop codebases up and running.

(In Rust, we've had this new target for a while, and it's where we're putting in all of our development efforts. We still technically support the emscripten target as well.)

No, it is not needed any more. I have a demo here: https://github.com/PetterS/clang-wasm

But be prepared to work without libc if you don't use emscripten. Writing a malloc is fun though!

Nice demo, thanks.

It's funny how technology go in waves. This reminds me more of programming microcontrollers than writing Web stuff, and yet this is the hot new thing!

> too lazy (or impatient) to compile LLVM from source

You can use llc from the release tarballs.

While they did an amazing job on improving the framework, compiler, and tools, a few important compatibility features weren't addressed:

- '-MT' and '-MM' options support (like in GCC)[1]

- '-M'/'-MF' options support (like in GCC)[2]

- 'MENUEX' menu resource section parsing (like in MSVC)[3]

Also, we recently found a problem[4] while compiling radare2 with 8.0.0 clang-cl for Windows. Hopefully, it will be addressed soon since the tool offers sanitizers support for the Windows platform, which is a blast.

[1] https://bugs.llvm.org/show_bug.cgi?id=10091

[2] https://bugs.llvm.org/show_bug.cgi?id=8312

[3] https://bugs.llvm.org/show_bug.cgi?id=40108

[4] https://bugs.llvm.org/show_bug.cgi?id=41128

Does anyone know what the status of the llvm riscv backend is? I haven’t heard about it in a while.

LLD just added support for that architecture with this release, so I assume it's still being actively developed.

rustc has support in-tree for

  riscv32imac-unknown-none-elf
  riscv32imc-unknown-none-elf
  riscv64gc-unknown-none-elf
  riscv64imac-unknown-none-elf

So, it's at least far enough along to have that turned on!

Nice, was just looking into this!

You have to

  $ rustup target add <triple>

to download the pre-compiled libraries, but then it should be a --target <triple> away! As far as I know anyway, I'm sure there are bugs since it's so new.

> -mspeculative-load-hardening Clang now has an option to enable Speculative Load Hardening.

I wonder -- which targets support this flag? And which ones need it (i.e. which are susceptible)?

Also, I didn't see it in the changelog -- does libc++ have std::execution::* yet?

I was able to get AMDGPU & Mesa-OpenCL working reliably on an AMD RX480 with this release.

On 6 and 7 some OpenCL kernels would consistently fail with illegal instruction problems.

If you've been using AMDGPU PRO just for OpenCL support, and prefer running mainline drivers, give AMDGPU a try on llvm8 and a recent kernel.

Wish they updated the Kaleidoscope tutorial.

I should also note that KLEE 2.0 was released[1] in line with LLVM 8.0 release. It is the first release in the last 2 years, so the amount of changes is huge. If you are using symbolic execution - I recommend you to check out this version.

[1] https://github.com/klee/klee/releases/tag/v2.0

Are LLVM releases always timed to align with Xcode releases these days? I guess most people expect new Xcode and iOS/Mac SDKs on Monday.

Not really, Clang and LLVM from Apple (the version that comes with Xcode) is usually behind the official LLVM release and it is also slightly modified/patched.

Really? What's happening on Monday? Seems like unusual timing for SDK updates, a few months early of the usual WWDC releases...

It'll just be a point/minor release. WWDC is where major releases are usually announced (iOS 13 and macOS 10.15 for the coming 2019 WWDC).

I think it's ~6 month cycles so it might end up lining up with an annual event for a while. But soon enough they'll probably be out of phase.

>I guess most people expect new Xcode and iOS/Mac SDKs on Monday.

Most people don't expect them then, and they'd be wrong if they do.

Apple just has one of the regular spring-time announcements for hardware and services products.

WWDC, when the new Xcode and iOS/Mac SDKs will be announced (but usually not released to non-devs until Fall), is, and has always been, in the summer (June).

(And there's another hardware/services announcement in Fall usually).

It's expected that iOS 12.2 is coming with Swift5, and ABI stability for the first time, as well as os-bundled libswift for the first time. Sounds like a semi major sdk update to me.

Hmm, the minor update with new Swing is indeed a good point.

Not the usual way it happens though. Usually those things came at WWDC.

It wouldn’t surprise me if Monday were television series, only.

Alternatively, it’s that plus “one more thing”, where that thing is big.

I’m thinking that because the 70% faster iPad and the 100% faster iMac apparently didn't make the cut for Monday.

https://news.ycombinator.com/item?id=19441297 links to the release announcement for the whole project, not just the LLVM module.

This link is definitely more interesting if you care about clang or clang tools.

The other post has no comments yet and the link is: https://lists.llvm.org/pipermail/llvm-announce/2019-March/00...

OK, we'll update this link from http://releases.llvm.org/8.0.0/docs/ReleaseNotes.html.

edit: nevermind

The link makes it sound like the switch happens after the 8.0.0 release.

No, it does not.

According to you reference link:

> We currently plan to install the new developer policy and add the new license in January 2019 after the LLVM 8.0 release has branched.

Also, the source archive for LLVM 8 still contains the old license.

Which means that the first release under the Apache 2 license should be LLVM 9.

Reply on news.ycombinator.com