I'm wondering if there are more opportunities in D for increased
optimization in compilers that have not been mined yet. I'm
specifically interested in the possibilities of D over and above
what is possible in C and C++ because of the characteristics of D
or because of our freedom to change compared with the inertia in
the C/C++ world.
A useful phrase I saw today: “declaration of intent given by the
programmer to the compiler”.
As well as the opportunities that exist in D as it stands and as
it is _used_ currently,
I wonder what could be achieved by enhancing the language or its
usage patterns
with new semantic restrictive markings that could be implemented
with varying degrees of disruptiveness (from zero, up to idiom
bans or even minor grammar changes [gulp!]). New attributes or
property markings have already been added, I believe, during the
history of D, which fall into this category. I'm also thinking of
things like pragmas, functions with magic names and so forth.
Examples from the wider world, for discussion, no guarantees they
allow increased optimisation:
* In C, the “restrict” marker
* In C++, the mechanism that makes possible optimised
move-constructors and a solution to temporary-object hell
* assert()’s possibilities: but only if it is native and not
deleted too early in the compiler stack - guarantees of the truth
of predicates and restriction of values to be in known ranges,
just as compilers can exploit prior truth of if-statements. Same
for static assert of course
* Contracts, invariants, pre- and postconditions’ many, many
delicious possibilities. Ideally, they need to be published, at
two extra levels: within the same module and globally so that
callers even from other translation units who have only the
prototype can have a richer spec to guide inlining with truly
first-class optimisation
* Custom calling conventions
* Some C compilers have magic to allow the declaration of an ISR.
Stretching the category of optimisation a bit perhaps, but
certainly does aid optimisation in the widest sense, because you
don't then have to have unnecessary extra function-calls just to
bolt assembler to a routine in C
* Similarly, inter-language calling mechanisms in general
* GCC and LDC’s extended asm interfacing specs, constraints and
other magic
* Non-return-function marking, first in GCC and then in C itself.
(iirc. And in C++?)
* the GCC "__builtin_expect()" / "likely()" and "unlikely()"
magic marker functions to aid branch-prediction, code layout, etc
* GCC’s “builtin_assume_aligned()” function
* The GCC -ffast-math switch allows (if I understand correctly)
the compiler to assume there are no IEEE floating-point
weirdnesses such as infinities, NaNs, denormals anywhere, or to
assume that the programmer just doesn't care. What if there were
a mechanism to give kind of control down to a much more
fine-grained level? (Such as
per-function/operator/block/expression/object/variable.)
Sorry it's such a paltry list. However discussion will I'm sure
expand it.
