On Fri, Jun 10, 2022 at 11:34 AM Lénárd Szolnoki via Std-Proposals <
std-proposals_at_[hidden]> 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
<https://twitter.com/RockingRoll777/status/1532812382564601857> about how
arcane `volatile` really is these days. It's not in *anybody's* muscle
memory.