News for hackers. Stuff that matters.
Re:What every compiler writer should know about programmers ... by aidenn0 on Thursday March 03, 2016 @06:55PM (#11221001)
The author doesn't understand the market demands for a compiler:

1) Customers who want their text-size to be as small as possible so they can shave $0.0015 off their BOM by using smaller ROM parts

2) Chip vendors who have 7 figure sales that will fall-through if they can't show a 0.7% higher Dhrystone MIPS (yes Dhrystone, the benchmark that was obsolete 20 years ago).

3) Managers who make buying decisions purely based on a set of their own pet benchmarks, with no regard to anything in this paper.

Damn right a compiler will take advantage of every optimization opportunity afforded by the standard. Good compilers will have ways of being much less aggressive about optimizations; I bet with gcc and clang each you have some -f flags that will disable certain optimizations (not to mention just good old -O0); I know most commercial compilers do.

[edit]

I would like to see some less-optimizable C standard catch on, so that there could be a mode common to multiple compilers that makes programmers happy. Unfortunately attempts to create such a dialect have failed to get off the ground.

[edit2]

Part of this is because there is less of a consensus on what are optimizations* and "optimizations" than the author would believe.

Re:What every compiler writer should know about programmers ... by AntonErtl on Saturday March 05, 2016 @01:22PM (#11230312)
As for the market demands on compilers, I hope that this paper influences that in more reasonable directions. In the meantime, I have nothing against having an option (or more) for "optimizations". Enabling new "optimizations" by default however has the effect of miscompiling existing programs and is not such a good idea. At the very least there should be one flag for disabling "optimizations" without disabling optimizations.

Concerning what are optimizations: If the observable behaviour does not change (even when there is undefined behaviour), it's an optimization. Also, register allocation and rearranging stuff in memory is an optimization (because programs that rely on that not changing break on maintenance). Other transformations are, at best, "optimizations". If you have any questions about specific transformations, please ask.