3 ms·

You do not need constexpr, just remove the "volatile" which I put into my example only to prevent the optimizer from specializing it: https://godbolt.org/z/fs8q

by uecker 1y ago

You do not need constexpr, just remove the "volatile" which I put into my example only to prevent the optimizer from specializing it: https://godbolt.org/z/fs8q3sdxK https://godbolt.org/z/fs8q3sdxK But what matters is run-time behavior for any input. And sorry, C++'s complexity still has the effect that the code is terrible: https://godbolt.org/z/vWfjjf8rP https://godbolt.org/z/vWfjjf8rP In C, the compiler can remove all error paths: https://godbolt.org/z/GGMcc6bxv https://godbolt.org/z/GGMcc6bxv

nly 1y ago
Not sure what you're talking about here. The cruft the assembly is because you enabled UBSAN. If you disable UBSAN then the exception throwing code paths go away.
- uecker 1y ago
  The point is that the error code paths should go avoid even with UBSAN because they are dead, but the optimizer is not able to see this anymore in C++.
aw1621107 1y ago
> But what matters is run-time behavior for any input. And sorry, C++'s complexity still has the effect that the code is terrible: https://godbolt.org/z/vWfjjf8rP https://godbolt.org/z/vWfjjf8rP > In C, the compiler can remove all error paths: https://godbolt.org/z/GGMcc6bxv https://godbolt.org/z/GGMcc6bxv For what it's worth, if you actually use the same flags for the C++ example (in particular, -fsanitize-trap) the C++ compilers improve quite a bit, with Clang getting fairly close to the GCC C output (https://godbolt.org/z/M3z5EaGKj https://godbolt.org/z/M3z5EaGKj ; note that GCC doesn't seem to eliminate the std::optional::value() check unless you use -O3). But perhaps more interestingly, if you make a simplified std::optional that still uses C++-specific features both Clang and GCC produce output that is very close to that from C/GCC: https://godbolt.org/z/PhEW7eT8x https://godbolt.org/z/PhEW7eT8x Removing I/O-related stuff makes this clearer: C: https://godbolt.org/z/e71s9E63f https://godbolt.org/z/e71s9E63f C++: https://godbolt.org/z/YnhdxYxY4 https://godbolt.org/z/YnhdxYxY4 (Clang seems unable to eliminate the UBSan overflow check for some reason?) Does make me wonder what exactly it is about std::optional that confuses the optimizers, and whether a similarly complex C maybe implementation can suffer from the same issues that std::optional appears to.

by uecker 1y ago

nly 1y ago

Not sure what you're talking about here. The cruft the assembly is because you enabled UBSAN. If you disable UBSAN then the exception throwing code paths go away.

uecker 1y ago
The point is that the error code paths should go avoid even with UBSAN because they are dead, but the optimizer is not able to see this anymore in C++.

aw1621107 1y ago

> But what matters is run-time behavior for any input. And sorry, C++'s complexity still has the effect that the code is terrible: https://godbolt.org/z/vWfjjf8rP https://godbolt.org/z/vWfjjf8rP > In C, the compiler can remove all error paths: https://godbolt.org/z/GGMcc6bxv https://godbolt.org/z/GGMcc6bxv For what it's worth, if you actually use the same flags for the C++ example (in particular, -fsanitize-trap) the C++ compilers improve quite a bit, with Clang getting fairly close to the GCC C output (https://godbolt.org/z/M3z5EaGKj https://godbolt.org/z/M3z5EaGKj ; note that GCC doesn't seem to eliminate the std::optional::value() check unless you use -O3). But perhaps more interestingly, if you make a simplified std::optional that still uses C++-specific features both Clang and GCC produce output that is very close to that from C/GCC: https://godbolt.org/z/PhEW7eT8x https://godbolt.org/z/PhEW7eT8x Removing I/O-related stuff makes this clearer: C: https://godbolt.org/z/e71s9E63f https://godbolt.org/z/e71s9E63f C++: https://godbolt.org/z/YnhdxYxY4 https://godbolt.org/z/YnhdxYxY4 (Clang seems unable to eliminate the UBSan overflow check for some reason?) Does make me wonder what exactly it is about std::optional that confuses the optimizers, and whether a similarly complex C maybe implementation can suffer from the same issues that std::optional appears to.