Hiding from the optimizer should be a last resort; far better to tell it
exactly where we want to disable optimizations, at as fine a level as
possible.

Also, framework authors will expect and have a right to general purpose
facilities. We thought that volatile automatics was such a facility; maybe
that was wrong, but there is definitely still scope for something similar,
not just ad hoc solutions to individual use cases.


On Fri, 10 Jun 2022, 22:09 Arthur O'Dwyer via Std-Proposals, <
std-proposals_at_[hidden]> 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
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>