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