There have just been a whole bunch of threads about these issues. It's you being disingenuous by picking out 2 specific things that are not a huge part of how optimizations are implemented. No one has claimed that those 2 things enable major optimizations. It's a strawman.
Conversation
I have a large list of things that don't enable major optimizations. Not sure which 2 things you think I'm picking out. So I'll repeat my point again: the UB feature that most helps perf is strict aliasing. Everything else is crumbs.
1
The basic memory safety guarantees provide a lot more broadly used information about memory dependencies / aliasing than type-based aliasing metadata. Even the guarantees for pointer arithmetic have a huge impact. Just try compiling code using iterators without those guarantees.
2
Simply taking away the basic memory safety and pointer arithmetic guarantees forbids most code motion (like hoisting out of loops), makes the compiler unable to see that tons of loops terminate or only access within the bounds of an object, etc. It kills most loop optimizations.
1
Even the simple loop optimizations, not just more aggressive things like unrolling and vectorization. The optimization stack is based on basic guarantees from the assumption that memory safety isn't broken. No data races, no out-of-bounds accesses, no use-after-free, etc.
2
If you force the compiler to assume that memory can change at any point, you forbid tons of optimization / code movement. Every single memory access has to act as a strong, sequential memory barrier. Even optimization in code without explicit pointers ends up disallowed.
1
This Tweet was deleted by the Tweet author. Learn more
Optimizations removing redundant null pointer checks are extremely important for performance, including for memory safe languages where it's never a safety issue. A memory safe language definitely shouldn't be punished with far worse performance due to the unsafety of C...
1
... and I don't think C programmers would be very accepting of Clang disabling a ton of optimizations that are standard for other languages. Programmers are already free to pass flags like -fwrapv -fno-strict-aliasing -fno-delete-null-pointer-checks to be more permissive.
1
GCC and LLVM aren't only C compilers. It doesn't make sense for them to restrict optimization based on C being an unsafe language. It makes sense for the frontend to support disabling optimizations. Note that Clang doesn't perform *any* of these optimizations by default.
1
You need to ask to enable optimization, and there are switches to make the language dialect more permissive (i.e. using a larger superset of standard C) in order to avoid having optimizations cause breakage. It also disables checks for the bugs as part of debugging/hardening.
For example if you pass -fwrapv, -fsanitize=undefined will no longer detect signed integer overflow. That includes the production-oriented mode without a runtime with -fsanitize=undefined -fsanitize-trap=undefined which is useful for hardening. It uses a more permissive language.