On Fri, Jun 10, 2022 at 4:43 PM Lénárd Szolnoki <cpp_at_[hidden]>
wrote:

> [...] The thing is, if I have a library funciton called "DoNotOptimize",
> but
> it fails to be an optimization barrier in some circumstances, then it's
> not a very good abstraction. Wouldn't it be nice if this could be a
> similar optimization barrier, LTO enabled or not? [...]

[...] I'm interested in optimization
> barriers in general, or maybe even more generally fine grained control
> of optimization hints/options within the code.
>
> > [...] All I'm saying is, if your goal is simply
> > to mystify the optimizing compiler as to whether a particular
> > variable is dead or whether a particular write to it can be hoisted,
> > literally all you have to do is escape that variable's address into a
> > different translation unit (which is exactly what
> > benchmark::DoNotOptimize does).
>
> Again, with LTO disabled.


I think I need to re-post this paragraph.

Here's another way to look at it: *"Optimization barrier" is not a
first-class principle.* Instead, the fundamental organizing principle is *"The
tool can't optimize what it can't see."* So, if you really really want
something not to be optimized, then you simply mentally reduce the problem
to "How can I make my optimizing tool *not see* this function?"
For an optimizing compiler, the answer is "put it in a different TU,"
problem solved.
For an optimizing linker, the answer might be "put it in a .so/DLL", or it
might be "You simply can't hide it; turn off the optimizer."
For a Perl script that greps for unused variable definitions and removes
them, the answer might be "add a dummy usage (void)x later in the file."

The appropriate mitigation *always* depends on what tool you're trying to
hide from.

–Arthur