No CTFE of function

[ag0aep6g via Digitalmars-d-learn]

On 08/27/2017 01:53 AM, Cecil Ward wrote:
> On Saturday, 26 August 2017 at 23:49:30 UTC, Cecil Ward wrote:
[...]
>> I think I understand, but I'm not sure. I should have explained 
>> properly. I suspect what I should have said was that I was expecting 
>> an _optimisation_ and I didn't see it. I thought that a specific 
>> instance of a call to my pure function that has all compile-time-known 
>> arguments would just produce generated code that returned an explicit 
>> constant that is worked out by CTFE calculation, replacing the actual 
>> code for the general function entirely. So for example
>>
>>     auto foo() { return bar( 2, 3 ); }
>>
>> (where bar is strongly pure and completely CTFE-able) should have been 
>> replaced by generated x64 code looking exactly literally like
>>     auto foo() { return 5; }
>> expect that the returned result would be a fixed-length literal array 
>> of 32-but numbers in my case (no dynamic arrays anywhere, these I 
>> believe potentially involve RTL calls and the allocator internally).
> 
> I was expecting this optimisation to 'return literal constant only' 
> because I have seen it before in other cases with GDC. Obviously 
> generating a call that involves running the algorithm at runtime is a 
> performance disaster when it certainly could have all been thrown away 
> in the particular case in point and been replaced by a return of a 
> precomputed value with zero runtime cost. So this is actually an issue 
> with specific compilers, but I was wondering if I have missed anything 
> about any D general rules that make CTFE evaluation practically impossible?

I don't know what might prevent the optimization.

You can force (actual) CTFE with an enum or static variable.
Then you don't have to rely on the optimizer. And the compiler will 
reject the code if you try something that can't be done at compile time.

Example:
----
auto foo() { enum r = bar(2, 3); return r; }
----

Please don't use the term "CTFE" for the optimization. The two are 
related, of course. The optimizer may literally evaluate functions at 
compile time. But I think we better reserve the acronym "CTFE" for the 
guaranteed/forced kind of precomputation, to avoid confusion.