Who's afraid of a big bad optimizing compiler?

Posted Jul 26, 2019 15:08 UTC (Fri) by jerojasro (guest, #98169)
In reply to: Who's afraid of a big bad optimizing compiler? by farnz
Parent article: Who's afraid of a big bad optimizing compiler?

hmm, I was thinking that the compiler only had to look for "global variables" (things syntactically declared as global), and add barriers/avoid reordering/etc.

but after reading both of your comments, I realized (hope I'm correct), that globals are *both*: things declared as global, *and also* anything allocated in the heap. And that last part is what makes automating all of these checks/guards such a performance hit, and worth bothering the programmer with handling manually the unsafe situations.

Man I'm glad I just concatenate strings for a living.

Who's afraid of a big bad optimizing compiler?

Posted Jul 26, 2019 15:32 UTC (Fri) by farnz (subscriber, #17727) [Link]

It's a bit worse than that - things in C are global in the sense of "need concurrency-awareness baked-in" if they are syntactically global, or if there is ever a pointer to the thing. That last covers all heap allocations, and any stack allocations whose address you take with &, and in turn means that you have to add barriers etc to all heap allocations plus some stack allocations.

And, of course, this is only going to help code that does not execute correctly on the C machine, as it ignores the semantics of the C machine. We don't want to strengthen the semantic guarantees of the C machine, since that results in the output code running slower (it needs more barriers, as more of the "internal" effects are now externally visible). So it only actually helps developers who dont actually understand what they're telling the computer to do - while this may be a common state, it's not necessarily something to encourage.