I don’t really see what point the author is trying to make. He seems to be arguing against a viewpoint that nobody actually holds.
Are there any compilers for any language that purposely produce broken code when optimizations are turned on? The closest I can think of are some GCC options related to floating point math that slightly change floating point semantics, but those have to be explicitly turned on and the docs are very clear that they may break things.
The reality is there are a lot of optimizations compilers can do that are 100% correct in every circumstance, or where the code can be analyzed and the optimization turned on only when it’s 100% safe. There’s really no reason not to continue research into optimizing compilers.
There’s a lot of things wrong with this argument, but effectively it’s one of those “My roof occasionally leaks, therefore I shouldn’t have a roof at all” lines of reasoning. Almost every compiler has a -O0 mode and gcc/clang have a gazillion flags to tune the passes the optimizer. If one of the automatic -O1 -O2 -OS modes doesn’t meet your needs you have a lot of options to go tune the loop-invariant code motion or escape analysis options or whatever pass you want to meet you needs.
“Compilers shouldn’t miscompile source code in an attempt to produce faster programs” is, taken at face value, tautological and inane. A compiler that miscompiles code is, by definition, broken. So, to be charitable, I assume that the author has become aware of an issue where a compiler has intentionally transformed a specific piece of source code into a specific executable whose behavior contradicts the behavior expected from the same source code in light of the language specifications. If this were true, the necessity of the author’s argument would have been significantly bolstered by providing examples. Alas.
Trying to have a compiler that’s stable and reliable and also meets the needs of these few people with extreme, possibly misguided, performance needs is a mistake.
I agree, but I think there is an incentive problem. To discourage this mistake, compiler development should be done and supported by people who prioritize stability and reliability over performance. In practice, compiler development is done by entities like Google, whose performance needs I think are extreme and possibly misguided.
I think MSVC scores well in this department in part because of better alignment of incentive.
I don’t really see what point the author is trying to make. He seems to be arguing against a viewpoint that nobody actually holds.
Are there any compilers for any language that purposely produce broken code when optimizations are turned on? The closest I can think of are some GCC options related to floating point math that slightly change floating point semantics, but those have to be explicitly turned on and the docs are very clear that they may break things.
The reality is there are a lot of optimizations compilers can do that are 100% correct in every circumstance, or where the code can be analyzed and the optimization turned on only when it’s 100% safe. There’s really no reason not to continue research into optimizing compilers.
There’s a lot of things wrong with this argument, but effectively it’s one of those “My roof occasionally leaks, therefore I shouldn’t have a roof at all” lines of reasoning. Almost every compiler has a -O0 mode and gcc/clang have a gazillion flags to tune the passes the optimizer. If one of the automatic -O1 -O2 -OS modes doesn’t meet your needs you have a lot of options to go tune the loop-invariant code motion or escape analysis options or whatever pass you want to meet you needs.
“Compilers shouldn’t miscompile source code in an attempt to produce faster programs” is, taken at face value, tautological and inane. A compiler that miscompiles code is, by definition, broken. So, to be charitable, I assume that the author has become aware of an issue where a compiler has intentionally transformed a specific piece of source code into a specific executable whose behavior contradicts the behavior expected from the same source code in light of the language specifications. If this were true, the necessity of the author’s argument would have been significantly bolstered by providing examples. Alas.
I agree, but I think there is an incentive problem. To discourage this mistake, compiler development should be done and supported by people who prioritize stability and reliability over performance. In practice, compiler development is done by entities like Google, whose performance needs I think are extreme and possibly misguided.
I think MSVC scores well in this department in part because of better alignment of incentive.
Also, Intel and AMD, who contribute a lot of patches to open-source compilers, and are intensely interested in benchmark performance.