Compile time function execution...

Reiner Pope xxxx at xxx.xxx
Thu Feb 15 22:17:31 PST 2007


Walter Bright wrote:
>> Viewing this as a more complex extension to inlining, I think the 
>> correct approach is to allow explicit annotations for 'only at 
>> runtime' and 'only at compile time'
> 
> I just don't see what is to be gained by this (and consider the extra 
> bloat in the language to provide such annotations). The language already 
> gives complete, absolute control over when a function is executed.
It's better for the user only to have complete control when desired. The 
compiler should infer the rest, but by a better policy than 'leave as 
much to runtime as possible', since such a policy misses optimization 
opportunities.

Unless I misunderstand, it seems like compile time function execution 
opens up a lot of optimization opportunities, yet the programmer is 
required to explicitly specify every time they should be used.


 From what I understood, this function execution was implemented by 
extending const-folding. Wasn't const-folding initially a form of 
optimization, to pre-evaluate things, so they didn't need to be 
evaluated at runtime?

Consider:

int sq(int val)
{
     return val*val;
}

void main()
{
     printf( sq(1024) );
}

Although sq() will probably be inlined, if it gets too big, then it 
won't. However, there is no reason that it can't be evaluated at 
compile-time, which would increase the runtime efficiency. Sure, the 
programmer could enforce compile-time evaluation by using

printf( eval!( sq(1024) ) );

but if the compiler can evaluate it automatically, then there would be 
no need for programmer annotations here.

I'm just agreeing with Michiel that there should be a compile-time 
switch tells the compiler to pre-evaluate as much as possible. This is 
an optimization because it means that some code doesn't need to be run 
at runtime. I just suggested the 'only at runtime' annotation so that 
the programmer has a safeguard against the compiler going wild with 
pre-evaluation, for situations like the compressed-code example you 
mentioned earlier.


> You can completely ignore and omit the eval!() and your code will run 
> just fine. The eval!() is only for those who wish to do some more 
> advanced tweaking.
For sure. However, what I referred to in my post was the similarity 
between requiring 'inline' in C++ to tell the compiler to optimize the 
function call and requiring eval!() in D to tell the compiler to 
pre-evaluate the function.


Cheers,

Reiner



More information about the Digitalmars-d mailing list