Clay language

[Walter Bright]

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.