Yes, instead of making assumptions about what the compiler can or can't see, it's better to just tell it to not look.

This [[dont_look]] function attribute is spelled [[gnu::noipa]] in gcc, I'm not aware of an equivalent for other compilers.


On 11 June 2022 07:39:44 BST, Bo Persson via Std-Proposals <std-proposals_at_[hidden]> wrote:
>On 2022-06-10 at 23:09, Arthur O'Dwyer via Std-Proposals wrote:
>> On Fri, Jun 10, 2022 at 4:43 PM Lénárd Szolnoki <cpp_at_[hidden] <mailto: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?"
>
>So perhaps what we need is a [[dont_look]] directive?
>
>
>
>
>--
>Std-Proposals mailing list
>Std-Proposals_at_[hidden]
>https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals