On Fri, Jun 10, 2022 at 11:34 AM Lénárd Szolnoki via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
How does this mesh with LTO? I would throw in [[gnu::noipa]] there for gcc, and at least [[gnu::noinline]] for clang (although noinline is probably not enough). But we are back at attributes. I certainly see the utility of fine grained optimisation hint attributes. I'm not sure if it needs standardisation, but it's not without precedent (likely/unlikely). 

Optimizing linkers operate at the machine-code level, not the C++ level. At least back when I worked on an optimizing linker (Green Hills' elxr, in the late 2000s), the linker wouldn't care about how your C++ syntax looked at all. It would happily inline, outline, or eliminate dead code no matter what your original function boundaries were. I wouldn't expect the subset of programmers who care about "setting `b` in a debugger" overlaps very much with the subset who care about "optimizing linkers." For those in the overlap, the easiest solution is "turn off your optimizing linker, then."
 
Also, I would like to add that this is nothing more than trading one language quirk that happens to be an optimisation barrier to an other (volatile vs function calls across TUs). If we deem optimization barriers to be useful for debugging/benchmarking, then having them as attributes makes perfect sense.

Well, `volatile` was never meant as a general optimization barrier; my mnemonic for `volatile` is
https://quuxplusone.github.io/blog/2022/01/28/volatile-means-it-really-happens/
Whereas the idea that "the compiler can't optimize what it can't see" is intuitively obvious, or at least obvious in hindsight, to anyone who has learned the traditional separate-compilation workflow of .cpp -> compiler -> .o -> linker -> .exe (which IMO should be every working programmer).  IOW, I agree with Jason that trading an idiosyncratic quirk for a newbie-friendly quirk is still a step in the right direction.

But 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.

my $.02,
Arthur

P.S. — I also notice that two different experts in this thread have mistyped `volatile` as `virtual`, which says a lot about how arcane `volatile` really is these days. It's not in anybody's muscle memory.