Rendered at 06:05:54 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
kazinator 3 hours ago [-]
> The question here is: can the compiler hoist the final division operation above assignment to x?
A division calculation not a visible effect. Therefore the question doesn't even m ake sense: it's asking: can we see something that is not a visible effect (division) before or after a visible effect (modification of a volatile object).
uecker 51 minutes ago [-]
But a division that traps because you divide by zero would prevent previous observable behavior from happening when hoisted above it. So it is not about the division itself but about the indirect effect on other behavior that can be observed.
Compilers already understand this: For example, they would not hoist a potentially trapping operation such as a division above a function call. The issue is that they did not apply this rule also to volatile accesses, but LLVM now does because this was fixed.
kazinator 48 minutes ago [-]
but "previous observable behavior" just means whatever actually happened, not that it was required to be previous.
uecker 32 minutes ago [-]
I do not understand what you mean by "whatever actually happened". The point is that before compilers were fixed previous volatile stores were not safe from compiler optimizations (GCC still has this bug, but now fixed on LLVM) or that even previous function calls were not safe (fixed in MSVC and GCC).
wahern 2 hours ago [-]
What if x is a register to toggle divide-by-zero exceptions? Normally this is none of the compilers business, but the whole point of volatile is a mechanism to express stuff like that, so it needs minimal semantics, e.g. no time traveling (compiler barrier), to be fit for purpose.
kazinator 2 hours ago [-]
x being a register connected to the processor's division machinery doesn't speak to the fact that division isn't a language-defined visible effect, and so the implementation is not required to schedule it in a certain way in relation to the store to x.
wahern 47 seconds ago [-]
Hmmmmm. It's late, but FWIW I think this comment from Martin from last year might be relevant: https://news.ycombinator.com/item?id=40838721 And I'm guessing the note that was added is fn#150 in C23. Volatile accesses aren't general memory barriers, but I think Martin's point is the potential for UB behavior means the compiler has to preserve the sequence order of the potentially UB operation relative to the volatile access.
A division calculation not a visible effect. Therefore the question doesn't even m ake sense: it's asking: can we see something that is not a visible effect (division) before or after a visible effect (modification of a volatile object).
Compilers already understand this: For example, they would not hoist a potentially trapping operation such as a division above a function call. The issue is that they did not apply this rule also to volatile accesses, but LLVM now does because this was fixed.