Rust Project goals for 2024

That paper is badly written - it makes two false assumptions (that optimizations rely on UB and are working with something that closely resembles C source code), and then stacks up a bunch of strawmen on top of that.

In practice, any modern compiler works by translating from C to some IR such that the semantics of the IR are the same, for all defined behaviour in the C source, as the semantics of the original C source. Optimizations then transform the IR in a way that maintains the IR's semantics, but which is either more optimal itself, or sets up the preconditions for a later optimization to transform the IR in a useful way; in the latter case, there's usually also a much later optimization pass that undoes the optimization if it didn't do something useful (e.g. LLVM has a pass that transforms loops into LCSSA form, various passes that can only fire if the loop is in LCSSA form, and an instcombine pass that removes the "surplus" IR involved in LCSSA form).

As a consequence of this, no optimization actually depends on UB; rather, the optimizations depend on the IR correctly capturing the meaning of the input code, so that they don't optimize in the wrong direction; you can use godbolt.org to examine the optimization passes that LLVM applies to your C or C++ code, and it'll show you the diff to the LLVM IR each optimization produces.

In that godbolt link, I've set the filters to "hide inconsequential passes" (those which don't change the IR for whatever reason), and changed the options to show the full module at a time, so that you can see how LLVM goes from the unoptimized input to the optimized machine code. Every one of those passes in green is doing something to the LLVM IR, and ignoring the C input; if the C to LLVM IR translation is wrong (e.g. because it gives the "wrong" defined behaviour to something that's UB), then the output will be wrong, too.

The fix is for compilers to define more UB in interesting and useful fashion; to choose everyone's favourite whipping-boy, C says that arithmetic on signed numbers cannot overflow, which means that in LLVM IR, C signed arithmetic puts the "nsw" modifier on the arithmetic operation. If Clang redefined overflow as "either calls abort() or wraps in twos' complement" (which ISO is perfectly happy for Clang to do), then Clang would have to remove the "nsw" modifier from LLVM arithmetic operations that it emits.

That then defines the arithmetic as twos' complement wrapping, and would ensure that LLVM optimizations that depend on the arithmetic not wrapping do not fire unless the compiler already knows via some other path that the arithmetic cannot wrap (e.g. because you're doing a / 10 + b / 10 + c / 10, which cannot wrap).

Sure, but the biggest issue is the lack of sane discussion between developers of compilers and user of compilers.

People are still arguing about even most basic and completely obvious facts.

Take the basis of the whole discussion: 100% of optimizations in 100% of compilers 100% of time depend on absence of UB in a translated program.

What could be simpler and more obvious? I mean: questions like why the contents of the EBX register no longer contained a copy of the executable’s instance handle when the executable entry point was called after upgrde to Window 8?. People just have to understand that at least some UBs are sufficiently nasty that the only way to treat these is to declare programs that do such things “completely broken” without any hope to treat them in the way other than “just don't do that or all bets are off” before any kind of dialogue can happen.

The only sane answer to the question about EBX could be “there was never any promises that EBX would contain something useful”. And, similarly, one may write many such “crazy”, “totally insane” seemingly portable programs! Programs that may read seemingly uninitialised variables or poke in the function internals (one is allowed to convert function pointers to integer and back in C), etc. Some of these programs are even pretty robust: my set/add example works on many compilers and surprising number of platforms even if I don't know of even a single optimizing compiler that doesn't break it.

But technically, as far as standard is concerned, that program belongs to the exact same class of programs as program with a nonempty source file does not end in a new-line character which is not immediately preceded by a backslash character or ends in a partial preprocessing token or comment!

Both the programs that are so patently insane that you may only find one version of one compiler which wouldn't break it (e.g. if program looks into it's own compiled binary code to get seed for a random number generator and then decodes assets using that number) and programs that can be compiled by pretty much any sane compiler and only break on obscure and rare compiler which couldn't handle file which doesn't have a new-line character at the very end are put in one large category: that's a program with UB.

As a result compiler users look on hundreds of UBs where majority of the list are totally silly UBs that are only there to make this or that compiler is standards compliant — and say that compilers may do better, they are not required to treat UBs as full carte blanche that allows one to do anything to the program that has such UB!

And then compiler developers hear that, obviously incorrect, assertion (because some UBs can only be treated as full carte blanche to do anything… e.g., as I have already said I don't know of any compiler that tries to keep programs that store random values on stack on one function and then try to access them in the other function working) and interpret it as total ignorance and misunderstanding on the side of compiler users… and if you are talking to someone who doesn't understand logic and couldn't reason about anything… what choice do you have? Ignore them…that's just natural, after all.