C idioms - Re: Right tool for compilers

On 6 Jan 2012 at 10:01, Fred Cisin wrote: Real optimization is perhaps the most difficult job a compiler writer faces--and indeed, the code dealing with optimization can be lengthier than the rest of the compiler code. Note that I'm not talking about simple things, such as eliminating invariants from loops and doing "peephole" work and other things local to the basic block. I mean true global optimization across all units of a program. Ones that can make whole subroutines disappear, or change parameter-passing mechanisms. The requirement is that optimized code, within reason, provide the same answer as the non-optimized version. That can be difficult if you're involved in floating point work. Even exploiting something as simple as the associative property in an expression can change the outcome of a computation. Some compilers have "unsafe optimization" switches to allow particularly aggressive optimization. However, that's of little use unless it can be turned off for critical code sections. On the other hand, there are some processors that are such beasts to manually write correct assembly for (the Intel i860 comes to mind), that you want to leave that task to a compiler with a good optimizer rather than use up your monthly allotment of Anacin. And there are compilers can can often generate better code than most assembly programmers, simply because the optimizer has a wider view and may have more "tricks" in its bag than the programmer. I find it difficult to believe that K&R ever intended that C would be the object of an automatic optimizer. Who would invent a pointer type that can point to *anything* if automatic optimization was intended? --Chuck