3 ms·

How do you decide whether an UB-optimization is insane or not? "I know it when I see it" may work for lawmakers, but it's not good enough for compiler developer

by ynik 3y ago

How do you decide whether an UB-optimization is insane or not? "I know it when I see it" may work for lawmakers, but it's not good enough for compiler developers. Because if you want to disable all UB-based optimizations, there's already a compiler flag that does that: -O0. Seriously, in a language as low level as C++, every optimization needs some form of assumptions, and UB is how we currently allow compilers to make those assumptions. Example: because it's undefined behavior to read pointers out-of-bounds, it is not possible for a valid program to scan a whole stack frame, so it is okay for the compiler to remove variables from the stack frame and instead store them in registers. Without UB-optimizations, you would need some others justification of why it is okay for the compiler to change the result of a stack scan. Or use -O0 which keeps all variables on the stack. (but that certainly will be slower!)

userbinator 3y ago
Look at Intel's compiler or MSVC, vs. GCC and LLVM. The former two are known to rarely exploit UB, yet are competitive and even faster with certain code (especially ICC) compared to the latter two. and UB is how we currently allow compilers to make those assumptions. No, the behaviour of the target hardware is what should guide that. Example: because it's undefined behavior to read pointers out-of-bounds, it is not possible for a valid program to scan a whole stack frame, so it is okay for the compiler to remove variables from the stack frame and instead store them in registers. UB has no bearing on that. If a variable has never had its address taken, then there's no expectation that it ever be in memory.
- gpderetta 3y ago
  > UB has no bearing on that. If a variable has never had its address taken, then there's no expectation that it ever be in memory. there were plenty of programs that expected specific stack layouts and were broken when compilers started optimizing stack spilling/register allocation more aggressively. Remember that register existed as a keyword. The address taken might have been a useful practical rule for some compiler, but I don't think it was ever endorsed by the standards (except for prohibiting taking the address of a register variable in C).

by ynik 3y ago

userbinator 3y ago

Look at Intel's compiler or MSVC, vs. GCC and LLVM. The former two are known to rarely exploit UB, yet are competitive and even faster with certain code (especially ICC) compared to the latter two. and UB is how we currently allow compilers to make those assumptions. No, the behaviour of the target hardware is what should guide that. Example: because it's undefined behavior to read pointers out-of-bounds, it is not possible for a valid program to scan a whole stack frame, so it is okay for the compiler to remove variables from the stack frame and instead store them in registers. UB has no bearing on that. If a variable has never had its address taken, then there's no expectation that it ever be in memory.

gpderetta 3y ago
> UB has no bearing on that. If a variable has never had its address taken, then there's no expectation that it ever be in memory. there were plenty of programs that expected specific stack layouts and were broken when compilers started optimizing stack spilling/register allocation more aggressively. Remember that register existed as a keyword. The address taken might have been a useful practical rule for some compiler, but I don't think it was ever endorsed by the standards (except for prohibiting taking the address of a register variable in C).