My general feelings on this subject: 1. I don't think we should care much about the ability to *SET* values of variables in optimized code. You can definitely do without that. So if a variable exists in two places, no problem, just register one of them.
2. It is much more important to have reasonable debugging for most users than the last mile of optimization. For me we should ensure that -O1 is still reasonably debuggable. The switch to GCC 4, at least in the Ada context, has significantly degraded -O1 debugging. I have found for instance that debugging the GNAT compiler itself, -O1 used to be perfectly fine, but now far too many arguments and variables disappear. 3. The quality of code at -O0 is really terrible compared to the competition (at least in the case of Ada), and large scale programs are just too big at -O0 to be practical (there is a big difference between a 50 megabyte image and a 100 megabyte image). So we really cannot rely on using -O0 for debugging. At -O1 we are more than competitive for performance with competing compilers. 4. In any case, most users really prefer to test and debug at the same optimization level that they will use for delivery. As noted above, -O0 is seldom practical for delivery (furthermore the voluminous extra code makes certification at the object level more work). -O1 is a fine compromise from a performance point of view, but needs to be debuggable. 5. Among our users we have relatively few who care about even a factor of 2 in performance, and VERY few who care about 10%. On the other hand we have lots of customers who definitely have severe problems with the lack of debuggability of -O1 code. 5. We have talked sometime about a -Od level or somesuch that would be fully debuggable. That's an interesting idea, but I think in practice it is more reasonable to try to ensure good debugging at -O1. Optimizations that significantly intefere with debugging should be moved to -O2. I think it is fine for -O2 to mean "optimize the heck out of the program, I really care about the last ounce of optimization, and I know debuggability will suffer."
