So what do I do if I want to microbenchmark a function with LTO on? Maybe because that's the configuration relevant for my application.


On 10 June 2022 16:54:31 BST, Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]> wrote:
>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.