Where should the type information be 231

On Thu, 31 Mar 2005 20:50:58 -0500, Herman Rubin

Many modern compilers will do constant propagation. If your pow function is in-lined, then the constant propagation will follow naturally, and you may end up with a similar result.

What would be *really* nice would be a compiler that contained an interpreter, so that constant expressions that included (user defined) functions could be evaluated to constants at compile time. Are there any compilers that can do that already? (I'd be pretty surprised if there wern't.)

I see what you're saying, now, but I don't believe that it fits the usual definitions of operator vs function, which (IMO) are strictly syntactical differences. For example, you would hardly call memcpy() an operator, but it can have many of the same sorts of optimisations performed on it, as an in-lined compiler "intrinsic".

What I'd really like to see is an ability to blur the line between what optimizations are built into the compiler, and what can be programmed independantly, as an interaction between the optimizer and the language. I know that lisp macros go a long way in this direction, but the syntax is sufficiently alian to put a lot of people off. I'd like a way to write a function in the normal "language" of the system, but include conditions that can only be resolved at compile time. Like: if you're in-lining me, and this argument is known to be in "this" range, use this different algorithm, otherwise do it this other way...

Maybe compilers already do all of the interesting tweaks that you could usefully think of? Things like unroll loop completely, for small constant loop count...

-- Andrew