Compilation strategy

[Timon Gehr]

On 12/18/2012 08:26 PM, H. S. Teoh wrote:
> On Tue, Dec 18, 2012 at 10:06:43AM -0800, Walter Bright wrote:
>> On 12/18/2012 9:49 AM, H. S. Teoh wrote:
>>> Is it too late to change CTFE to work via native code?
>>
>> No, because doing so involves zero language changes. It is purely a
>> quality-of-implementation issue.
>
> Well, that much is obvious; I was just wondering if the current
> implementation will require too much effort to make it work with native
> code CTFE.
>
>
>>> Besides the effort required to rework the existing code (and perhaps
>>> the cross-compiling issue, though I don't see it as a major issue),
>>
>> Um, it does introduce major support costs for porting to different CPU
>> targets.
> [...]
>
> Could you elaborate? In my mind, there's not much additional cost to
> what's already involved in targeting a particular CPU in the first
> place. Since the CPU is already targeted, we generate native code for it
> and run that during CTFE.
> ...

The generated native code would need to be different in order to support 
proper error reporting and dependency handling. (The generated code must 
be able to communicate with the analyzer/jit compiler.)

The compiler does not have the full picture during analysis. It needs to 
figure out what information a CTFE-call depends on. The only way that 
works in general is running it.


Eg:

string good(){
     mixin(foo(0,()=>good())); // ok, delegate never called
}

string bad(){
     mixin(foo(1,()=>bad())); // error, need body of bad to generate 
body of bad
}

string foo(bool b, string delegate() dg){
     if(b) return dg();
     return q{return "return 0;";};
}