LWN: Comments on "Calibrating your fear of big bad optimizing compilers"

Calibrating your fear of big bad optimizing compilers

klempner — Tue, 15 Oct 2019 13:37:40 +0000

The one thing that jumps out is the invented load issue with #5, which is a problem that relaxed loads and stores don't have but apparently a STORE_ONCE/LOAD_ONCE pair do.

Calibrating your fear of big bad optimizing compilers

ThinkRob — Mon, 14 Oct 2019 21:25:18 +0000

Wow! Yet again, another excellent deep dive article by LWN!

LWN is really second to none when it comes to this sort of in-depth, technical-yet-approachable content.

Keep up the fantastic work!

Calibrating your fear of big bad optimizing compilers

rweikusat2 — Mon, 14 Oct 2019 17:47:41 +0000

The "optimized away" in gdb output does not mean the compiler "pessimized" the source code by adding gratuitious memory accesses to the generated machine code. It means that the value of some source-level named object isn't available to the debugger because it losts its identity in translation: There was no reason to allocate a memory location for it, hence, it became a 'virtual' entity whose value (or values) only ever live in a register or - over the course of a given codepath - some set of registers the debugger cannot map back to the name.

Calibrating your fear of big bad optimizing compilers

hsivonen — Sat, 12 Oct 2019 19:12:28 +0000

Right. The C++11/C11 memory model has just UB and doesn’t say which thread of execution experiences the UB. For use cases like kernel vs. userland, hypervisor vs. guest, Web browser UI vs. renderer, and Wasm host vs. Wasm program, you want to have things defined such that the more privileged side can’t experience UB if the less privileged side doesn’t follow the rules.

Calibrating your fear of big bad optimizing compilers

excors — Sat, 12 Oct 2019 16:47:03 +0000

> (and we don't trust the data, so if another thread with access to that data changes it, that is their problem.)

If the access from the kernel is undefined behaviour (because another user thread modified that memory in violation of the rules), that's the kernel's problem. Undefined behaviour doesn't just mean the kernel will read an incorrect value, it means absolutely anything could happen (and would happen with kernel privileges).

Calibrating your fear of big bad optimizing compilers

scientes — Sat, 12 Oct 2019 16:03:41 +0000

>so using atomics to access userland memory from the kernel is technically UB.

But don't we only look at user-land data from the same thread that sent the data, so there are no races (and we don't trust the data, so if another thread with access to that data changes it, that is their problem.)

Calibrating your fear of big bad optimizing compilers

hsivonen — Sat, 12 Oct 2019 09:17:41 +0000

Atomics require the other thread of execution to be conforming to the C++1/C11 memory model. There is no such guarantee for userland processes, so using atomics to access userland memory from the kernel is technically UB.

The only thing in C or C++ that allows you to access (in a non-UB way) memory that doesn’t participate in the memory model is volatile, but since the use case it is designed for is memory-mapped devices, it inhibits more optimizations than would be necessary for the use cases of kernel accessing userland memory when responding to a syscall, a hypervisor accessing guest memory when implementing a virtual device, or a Wasm host assessing a SharedArrayBuffer Wasm heap when responing to a call to a host service.

Considering that this type of software is typically implemented in languages that inherit the C++11 memory model (C++ itself plus C11 and Rust), it’s surprising that this facility is missing.

Calibrating your fear of big bad optimizing compilers

scientes — Fri, 11 Oct 2019 21:58:56 +0000

Nevermind.

Calibrating your fear of big bad optimizing compilers

scientes — Fri, 11 Oct 2019 21:30:11 +0000

The C++ memory model atomics are way easier to use than these kernel macros that predate them and use volatile. Using volatile like this, now that atomics exists, is code smell, IMHO. I am not sure if C exposes them, but it should.

https://www.llvm.org/docs/Atomics.html

Calibrating your fear of big bad optimizing compilers

PaulMcKenney — Fri, 11 Oct 2019 18:36:24 +0000

Good catch! I will send a suggested update once I get to a place where my laptop containing the article source has Internet connectivity. And apologies for the unscheduled literary cryptography!!!

Calibrating your fear of big bad optimizing compilers

vegard — Fri, 11 Oct 2019 14:30:08 +0000

This is kind of cryptic.

There's a link to a previous article hidden in a single word of the second paragraph: "As noted earlier [...]"

Later it launches into "A key point from the first article" and I go: Huh? Which first article? Maybe I can't read.

For those who know nothing about LKMM (like me) this is a pretty tough read. The introduction could have been gentler, or at least the link to the previous article should be much more prominent, i.e. a "This article is based on so-and-so and the reader is urged to read it first"-style disclaimer.