Clay language

[Stanislav Blinov]

On 12/28/2010 12:48 AM, bearophile wrote:
> Walter:
>
>>>> Additional optimizations should not be prevented, however.
>
>> I.e. the same situation as today.
>
> It's a different situation. See this part:
>
>> It should be possible to specify
>> that one or more of these optimizations is required, and have the compiler
>> raise an error when they cannot be applied for some reason.<
>
> The idea is to allow the code (I presume with the help of some annotations) to require certain optimizations (some are listed here, and they are more complex than replacing a*4 with a<<2:https://github.com/jckarter/clay/wiki/Guaranteed-optimizations ), if the compiler doesn't perform a specific optimization (that I presume an annotation asks for), a compilation error is raised, and the programmer is forced to change the code, removing the annotation or doing something else. This also means that a conforming Clay compiler must perform a certain number of not simple optimizations (further optimizations are accepted. So the point is for a specific piece of code to have a common level of optimization).
>
> I don't know if all this is possible (this meta-feature is in the wish list of Clay), but if it's doable then it sounds like a very good thing to add to D3.
>

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).
I can't think of a way to blame the compiler if it can't optimize code 
the way you want (and blaming in this context means forcing error 
message instead of using another code generation path) - this, in 
effect, is like asking compiler to reject perfectly valid code. It also 
"narrows" (is this a verb in English?) selection of compilers for your 
code (because optimization is at the very least a thing a compiler may 
or may not have).

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*.