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
> On Wednesday, 2 August 2017 at 18:11:25 UTC, Moritz Maxeiner
>> 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 (->
>> duplicated effort)
>>  https://github.com/UplinkCoder/dmd/tree/newCTFE
>>  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