Bug 936 – Optimization by compiler hints

The Microsoft C++ compiler used compiler hints such as assume(var<[constant]); to help the compiler optimize code. DMD could also benefit from similar hints to improve optimizations. Actually, rather than removing "assert"s from debug code, why not use it's conditions to optimize code in release version?

If such things are added I would hope they are added as pragmas rather than language keywords, becuase these sorts of hints have a way of becoming useless and even counterproductive as compilers get smarter. C.f. the C 'register' keyword.

The reporter's point is that one of these ways in which compilers can become smarter is by using assert expressions as optimisation hints. Why add a pragma as an extra way of doing the same thing?

I've never heard of "assume" and don't know what it does, so I thought he was suggesting to add a new "assume" keyword and other "compiler hints such as" that to D. Taking hints from existing expressions like assert() would be fine by me. Taking hints from contracts would also be cool.

(In reply to comment #2) > The reporter's point is that one of these ways in which compilers can become > smarter is by using assert expressions as optimisation hints. Why add a pragma > as an extra way of doing the same thing? An assert indicates "this is true". A pragma could add a way to say "this is *probably* true". The compiler could then perhaps emit code optimized to run the most likely path as fast as possible, at the expense of less likely paths. For instance, you could tell it that it's unlikely a function returned an error code (let's assume this was a C function that doesn't know about exceptions) so perhaps the code for when the error occurs should be the one performing a jump instruction[1]. [1]: I read somewhere that conditional jumps are less expensive when the condition does not hold. I have no idea if this is still the case for modern processors, this is just an example.

When debugging code,conditions in asserts are expected to be *always* true, and not probably. If we intent to have probable conditions, the release code would have some sort of handling of such situations. Pragmas for probabilities are not so useful. Consider that in a switch a case is more probable than other, the programmer would just change the order of cases, and not adding a pragma to do the same thing which would just bloat the code. As an example, in a getCurrentDay() function, we expect the return value never to be bigger than 31, and out{} contract would be perfect to (possibly) optimize the code. It is a certainty, not a probability.

This is just wishful discussion from the past. Things like that should have a DIP and some proof of concept.