Stanislav Blinov wrote:
Frankly, I'd warmly back Walter on this one. "Requiring" optimizations is similar to asking a compiler to do something it's not supposed to. In the end, optimization is a means compiler uses to make generated code more "efficient", which is a subjective term and can only be approximated by e.g. instruction count per operation, memory request rate, overall code size, etc. But it's not a "conuer-the-world" means. On one hand, demanding a certain optimization means that programmer knows it's possible (e.g, programmer can do it herself with, e.g., inline asm), but on the other hand it must mean that it's applicable to used language instructions (but language or compiler may not be smart enough to figure out "optimizable" spot).
Another problem with specified optimizations is that computer architectures change, and the right optimizations to use can change dramatically (and has).
I think that what *would* be useful is *disallowing* optimizations for certain parts of code. I mean, (if we talk about dmd or many C/C++ compilers), with -O flag, the compiler is given carte blanche on code generation, which may or may not lead to certain "unexpected" differences between unoptimized and optimized code. For example, several times I ran across nasty spots with optimized-out temporaries in C++ (think of relying on constructor calls). I can't remember the exact cases (shame on me, I haven't thought about storing a test-case database at that point), but I do remember well the frustration. This disallowing is not so easy as it seems (not to talk about requiring), because optimizing compiler can employ certain assumptions on overall code generation strategy, which may not fit well this "external control". But overall, asking *not* to do certain things is a lot more liberal than asking to *do the things in the exact way*.
This is the issue with "implementation defined" behavior. D tries to minimize that.
