I think the fact we need special use cases is a good argument for volatile here.
-------- Original Message --------
On Jun 10, 2022, 17:09, Arthur O'Dwyer via Std-Proposals wrote:

> 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