
LLVM 4.0.0 - zmodem
http://lists.llvm.org/pipermail/llvm-announce/2017-March/000073.html
======
bajsejohannes
> thanks to Zhendong Su and his team whose fuzz testing prevented many bugs
> going into the release.

[http://web.cs.ucdavis.edu/~su/](http://web.cs.ucdavis.edu/~su/) claims 1228
bugs found (counting both LLVM and GCC). Impressive!

~~~
nightcracker
With fuzzing it's possible to find distinct bugs (or at least bugs that
trigger in distinct code locations) without ever further investigating the bug
in person.

Your bug report can simply consist of "this input file causes a compiler
crash".

~~~
willvarfar
Indeed! On the Mill project we leave boxes crunching hours and hours of
csmith/creduce, and we don't watch them do it :)

SPE looks to be very nice too.

~~~
gravypod
What's the Mill project? Is that the "new computer" thing or am I missing
something.

~~~
willvarfar
Yeap that's the project :)

We have our own llvm backend which is a front end to our own "specialiser".

We use csmith to fuzz for compiler bugs and creduce to reduce them. This
starts with C and we even validate the output of the sim against clang x86
output.

~~~
tmccrmck
How should someone go about contributing to your LLVM backend?

~~~
willvarfar
[http://millcomputing.com/#JoinUs](http://millcomputing.com/#JoinUs) :)

[http://millcomputing.com/topic/mill-computing-
in-2017/](http://millcomputing.com/topic/mill-computing-in-2017/) is our plan
this year

~~~
gravypod
So it is meant to be a different architecture? What market is it targeting?

Is mill low power, high performance, embeded, radiation hardened, etc? Will it
come in small packages with RAM and ROM on the die? Will it support a
different architectural view (maybe all the memory will be non-volatile)?

A lot of questions and very little answered in the page.

------
opt-viewer
Looks like it didn't make the release notes but one of the features new for
this release is opt-viewer. It's useful for finding the rationale why some bit
of code was/wasn't optimized. It's a WIP but usable today.

I made a demo [1] for this tool.

[1] [https://github.com/androm3da/optviewer-
demo](https://github.com/androm3da/optviewer-demo)

------
lossolo
LLVM Coroutines - This is the most exciting thing for me. Gor Nishanov in his
videos explains how coroutines are implemented and how are optimized by LLVM.
Asynchronous IO code will be so easy to write and so efficient. Context switch
in cost of function call, you can have billions of those coroutines, heap
allocation elision (in certain cases). Can't wait for coroutines to land in
Clang.

I am a big fan of Go gorutines so Networking TS and Coroutines TS made me very
happy, connecting both and having it in standard will be great. Just a shame
that for Networking TS integration we will need to wait for C++20.

~~~
wahern
Go-style coroutines will still be more efficient and more elegant than C++
coroutines. Goroutines are stackful, whereas in C++ you'll need to manually
chain coroutines. That means a dynamic allocation and deallocation for _each_
call frame in the chain. That's more efficient than JavaScript-style
continuation closures, but in many situations still far more work than would
be required for stackful coroutines.

Everything described in Gor Nishanov's video applies equally to stackful vs
non-stackful coroutines. That is, the code conciseness, composability, and
performance advantages of non-stackful coroutines are even greater with
stackful coroutines.

Nishanov dismisses stackful coroutines out-of-hand because to be memory
efficient one would need relocatable (i.e. growable) stacks. But that begs the
question of how costly it would be to actually make the stack relocatable. I
would assume that in a language like C++ where stack layout must already be
recorded in detail to support exceptions, that efficiently relocatable stacks
wouldn't be too difficult to implement.

At the end of the day, without stackful coroutines networking still won't be
as elegant as in Go. And for maximum performance, state machines (e.g. using
computed gotos) will still be useful. You'll either need to sacrifice code
clarity and composition by explicitly minimizing chains, or you'll sacrifice
performance by having deep coroutine chains.

~~~
pcwalton
> Nishanov dismisses stackful coroutines out-of-hand because to be memory
> efficient one would need relocatable (i.e. growable) stacks. But that begs
> the question of how costly it would be to actually make the stack
> relocatable. I would assume that in a language like C++ where stack layout
> must already be recorded in detail to support exceptions, that efficiently
> relocatable stacks wouldn't be too difficult to implement.

No, this is a common misconception. Unwind tables only store enough
information to be able to _locate_ each object that has to be destroyed. It's
an entirely different matter to _move_ those objects, because a system that
does that has to be able to find all outstanding pointers to an moved object
in order to update them. It's legal, and ubiquitous, in C++ to hide pointers
to objects in places that the compiler has no knowledge of. Thus moving GC as
it's usually implemented is generally impossible (outside of very fragile and
application-specific domains like Chrome's Oilpan).

The best you can do in an uncooperative environment like that of C++ is to
allocate large regions of a 64-bit address space and page your stacks in on
demand. (Note that this setup is gets awfully close to threads, which is not a
coincidence—I think stackful coroutines and threads are essentially the same
concept.)

~~~
mkup
> I think stackful coroutines and threads are essentially the same concept.

I think "fibers" is more correct term here: "stackful coroutines and fibers
are essentially the same concept".

In Win32, each process consists of threads, and each thread consists of
fibers. Each fiber has its own stack. Userspace code can switch fibers with
SwitchToFiber() API, kernel never switches fibers (kernel's unit of scheduling
is entire thread).

------
pjmlp
Love the improvements to clang-tidy!

[http://releases.llvm.org/4.0.0/tools/clang/tools/extra/docs/...](http://releases.llvm.org/4.0.0/tools/clang/tools/extra/docs/ReleaseNotes.html#improvements-
to-clang-tidy)

Congratulations on the work. Also nice to see that OCaml bindings are still
being taken care of.

~~~
danieljh
Absolutely. The following two new checks are impressive and should be on by
default.

 _New misc-move-forwarding-reference check Warns when std::move is applied to
a forwarding reference instead of std::forward._

[http://clang.llvm.org/extra/clang-tidy/checks/misc-move-
forw...](http://clang.llvm.org/extra/clang-tidy/checks/misc-move-forwarding-
reference.html)

 _New misc-use-after-move check Warns if an object is used after it has been
moved, without an intervening reinitialization._

[http://clang.llvm.org/extra/clang-tidy/checks/misc-use-
after...](http://clang.llvm.org/extra/clang-tidy/checks/misc-use-after-
move.html)

The use-after-move check has its limitations which make sense considering the
"unspecified but valid state" moved from objects are in. From reading the
design document the cases they handle should catch common ownership issues,
though. Great step in the right direction for sure.

Implementation: [https://github.com/llvm-mirror/clang-tools-
extra/blob/master...](https://github.com/llvm-mirror/clang-tools-
extra/blob/master/clang-tidy/misc/UseAfterMoveCheck.cpp)

Related: [https://doc.rust-lang.org/book/ownership.html](https://doc.rust-
lang.org/book/ownership.html)

------
falcolas
> Stable updates to this release will be versioned 4.0.x

/nit Semantic versioning (or communication) failure. I would think that
"stable updates" would represent minor releases (i.e. 4.x.0), not bugfix-style
patches. Unless all new features will be present in major releases instead of
"stable updates"?

~~~
pavanky
They have their reasoning behind this scheme over here:
[http://blog.llvm.org/2016/12/llvms-new-versioning-
scheme.htm...](http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.html)

I personally do not agree with their line of reasoning.

~~~
falcolas
OK, so indeed, no features in between major releases.

It's also somewhat unfortunate that, in their words, "every [six month]
release is also API breaking". How can you create a stable product that
targets a constantly breaking API (short of picking a version and sticking
with it)?

Of course, I'm a biased, since I consider stable to be measured in years, not
months; certainly not the current trend.

~~~
SamBam
But major releases are always expected to be API-breaking, right? Isn't that
basically the (SemVer, at least) definition of a major vs minor release?

Nothing's forcing anyone to keep up to date, though, so anyone can pick a
version and stick with it as long as they like. (So long as they keep making
patches for at least the previous version for major bugs...)

~~~
pavanky
That results in half a dozen versions of LLVM libraries installed on a given
machine instead of 1.

~~~
kbenson
When it comes to a compiler, I think I would rather have a statically linked
LLVM in the compiler than a shared object anyway, which would make this moot.

------
javajosh
Ha, was just reading
[http://aosabook.org/en/llvm.html](http://aosabook.org/en/llvm.html).

(Really like that LLVM IR. Does anyone code in it directly? Was also thinking
it would be interesting to port Knuth's MMIX examples to it.)

~~~
mhh__
Nobody actually programs in the IR of a compiler, except for (say) tests and
debugging. The IR is not usually designed to be read to by humans, although
LLVM is actually very readable (But still rather tedious).

If you looked at, just for an example, the IR used in the dmd d compiler,
using (Walter Bright's) Digital Mars backend then you'd notice that the IR is
not trivial to access at all. Last time I checked, you had to actually dive
into the backend code (I'm pretty sure there's an undocumented flag/switch
that I'm missing somewhere) to get the IR out of the compiler. In fairly sharp
contrast to this, getting the IR (in a textual format!) is normally as simple
as using -emit-llvm when compiling. This is part of the revolution (~Slight~
exaggeration) that LLVM brought about in compiler design: Compared to most
other compilers, LLVM is designed to be very portable. The only compiler, of
similar stature, like it is GCC. GCC is much better than it was, I'd imagine
because of the competition from LLVM/Clang.

Tangent Aside: The LLVM IR textual format is not guaranteed to be stable _at
all_. It's also not particularly nice to program in, and also it uses SSA form
so it's not suitable for humane consumption. It looks like a high level
programming language, but it really isn't. IR is designed to be generated,
bullied and discard by the compiler.

If you want to punish yourself, the LLVM project does contain interpreters and
compilers just for IR in a file. If I remember correctly, Clang will compile
anything with a ?.ll? file as IR.

You can see all the optimisation passes in action here:
[https://godbolt.org/g/uZH3UD](https://godbolt.org/g/uZH3UD)

~~~
nickpsecurity
"Nobody actually programs in the IR of a compiler"

It's called LISP. It is a niche style, I'll give you. ;)

~~~
mhh__
:-). _I think_ GCC has/had IR's that are LISP like.

------
grassfedcode
I'm trying to add support for lldb to a gdb frontend
([https://github.com/cs01/gdbgui/](https://github.com/cs01/gdbgui/)), and need
a gdb-mi compatible interface to do it.

lldb-mi exists, but its compatibility with gdb's mi2 api is incomplete. Does
anyone know of a more compatible api to gdb-mi2 commands, or if there are
plans to improve lldb-mi's?

------
self_awareness
Visual Studio is already at version 2017, and LLVM is only at 4, they need to
catch up real quick! /ducks

~~~
snnn
VS is slowing down. VC++ 2017 is VC++ 14.1, not 15.0

------
mark-r
Too bad they didn't use more aggressive aggressive grammar checking.

------
amyjess
I wish they'd do what GCC does and just eliminate the middle number entirely.

~~~
SamBam
But semver is a pretty meaningful standard. Why not stick to it, even if you
don't plan on adding non-API-breaking new features?

------
futurix
Version number inflation strikes another software package, although at least
it is not as bad as Chrome or Firefox.

~~~
jupp0r
It's not like there is a shortage of Integers, you know...

~~~
shmageggy
Unfortunately though, there is a shortage of capacity for our mental
representation of them. It's pretty easy to remember whether I'm on version 3
or 4, less so for versions 3713 and 3714.

~~~
w-m
Your mind would just skip the 371 though, like it does with year dates, as the
371 would be the same for a long time. And you're back to version 3 or 4.

------
aslammuet
[http://llvm.org/demo/](http://llvm.org/demo/)

Demo page is not working. Is there any other page that makes me understand
what really is it and where it is helpful.

~~~
kebolio
LLVM is a compiler toolkit, used by, for example, Clang for C/C++/Objective-C,
Rust, and various libraries like Mesa.

