On Thu, 26 Sept 2024 at 09:40, Jonas Oberhauser <jonas.oberhau...@huaweicloud.com> wrote: > > Boqun seems to be unhappy with a barrier though, because it would > theoretically also forbid unrelated optimizations.
Well, doing a "barrier()" is kind of a big hammer thing, but honestly, I don't think we've ever seen any real situation where it makes a noticeable difference. Yes, it can pessimize compiler output more than strictly necessary, but the kind of code generation issues it causes tends to be the non-problematic kind (and particularly the kind that even a trivial OoO core will deal with well). We do have some more directed compiler barriers available, and this code might be able to use OPTIMIZER_HIDE_VAR() for example. It's kind of a "single variable value barrier". Honestly, we don't use it much. It just tends to be _too_specific. But it is there if somebody wants to use it. > But I have not seen any evidence that there are any unrelated > optimizations going on in the first place that would be forbidden by this. Compared to something like "smp_mb()", which is not just a compiler barrier but also generates typically very expensive instructions that completely mess with an OoO core, a regular compiler barrier is a complete non-issue. When you have those two close to each other, you'd have to make up some very odd situation where the plain "barrier()" is even noticeable. Linus