JIT for CTFE

Moritz Maxeiner via digitalmars-d-ldc digitalmars-d-ldc at puremagic.com
Wed Aug 2 13:29:42 PDT 2017


On Wednesday, 2 August 2017 at 18:36:53 UTC, Moinak Bhattacharyya 
wrote:
> On Wednesday, 2 August 2017 at 18:11:25 UTC, Moritz Maxeiner 
> wrote:
>> On Wednesday, 2 August 2017 at 17:42:05 UTC, Moinak 
>> Bhattacharyya wrote:
>>> Has the JIT (ORCJIT) been looked into to take the place of 
>>> the interpreter for CTFE? It seems to me this would 
>>> drastically widen the scope of CTFE (ie you could now run 
>>> arbitrary code at compile time with an appropriate symbol 
>>> resolver) and would simplify the codebase too. Thoughts?
>>
>> Points against:
>> - CTFE is part of the frontend shared between D compilers (-> 
>> increased maintenance costs)
>> - There is a newCTFE in the works by Stefan Koch[1] (-> 
>> duplicated effort)
>>
>> [1] https://github.com/UplinkCoder/dmd/tree/newCTFE
>> [2] https://github.com/UplinkCoder/dmd/tree/newCTFE_LLVMBackend
>
> The newCTFE, while a worthwhile effort, is still an interpreter 
> and is rendered redundant by JIT'ing.

No. It is a generic API (from the frontend's perspective) for 
which the default implementation happens to be a new interpreter. 
There is also an LLVM backed JIT implementation, which I have 
linked to in the post you quoted (-> newCTFE_LLVMBackend).


More information about the digitalmars-d-ldc mailing list