Date: Fri, 10 Jun 2022 13:27:20 -0500
On Fri, Jun 10, 2022, at 10:34, Lénárd Szolnoki via Std-Proposals wrote:
> 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.
In addition to better communicating what is going on, an attribute instantly implies [likely] or [not likely] which makes it better. It also allows other optimizations that volatile turns off even though they don't matter. The attribute also allows an implementation to add some form of "but this really is release a where a debugger will not be run" compile flag (different from relWithDebInfo which I ship with) thus eliminating the code. It also allows an implementation to skip the if, and put something into the debug information so the debugger just sets a breakpoint where the if would have been and jumps to the code.
Those are 3 options that I can think of. I'm sure there are people smarter than me who can think of even more if they put for the effort. However so long as we constrain our implementation to "you don't know what is going on so don't optimize at all" it isn't worth thinking about what else can be done if more information was granted.
> 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.
In addition to better communicating what is going on, an attribute instantly implies [likely] or [not likely] which makes it better. It also allows other optimizations that volatile turns off even though they don't matter. The attribute also allows an implementation to add some form of "but this really is release a where a debugger will not be run" compile flag (different from relWithDebInfo which I ship with) thus eliminating the code. It also allows an implementation to skip the if, and put something into the debug information so the debugger just sets a breakpoint where the if would have been and jumps to the code.
Those are 3 options that I can think of. I'm sure there are people smarter than me who can think of even more if they put for the effort. However so long as we constrain our implementation to "you don't know what is going on so don't optimize at all" it isn't worth thinking about what else can be done if more information was granted.
Received on 2022-06-10 18:27:42