How about a 100% CTFE?

Timon Gehr timon.gehr at gmx.ch
Tue Nov 8 16:26:08 PST 2011


On 11/08/2011 07:35 PM, Martin Nowak wrote:
> On Tue, 08 Nov 2011 09:08:49 +0100, Don <nospam at nospam.com> wrote:
>
>> On 07.11.2011 21:36, Martin Nowak wrote:
>>> On Mon, 07 Nov 2011 20:42:17 +0100, Trass3r <un at known.com> wrote:
>>>
>>>>>>> version(ARM)
>>>>>>> {
>>>>>>> immutable X = armSpecificCode(); // you want to run this on an
>>>>>>> X86???
>>>>>>> }
>>>>>>>
>>>>>> I've always thought that it would be worthwhile to experiment with
>>>>>> LLVM's JIT engine here.
>>>>>> But as has been said quite some care will be necessary for cross
>>>>>> compilation.
>>>>>> Allowing arbitrary non-pure functions would cause lots troubles.
>>>>>
>>>>> Yeah, I think JIT for CTFE would be *very* interesting. But mainly
>>>>> for reasons of speed rather than functionality.
>>>>
>>>> How would JIT work in the above case?
>>>
>>> You would need to do JIT a target agnostic IR.
>>
>> Yeah, it's only the glue layer which needs to change. The main
>> complexity is dealing with pointers.
>
> Currently it only seems viable for strongly pure functions.

The JIT could just translate impure and unsafe constructs to 
exceptions/errors being thrown (or similar). It would then work the same 
way as it does now.


> One would still need to be very careful about target dependencies
> through libc calls (sinl et.al.),
> marshalling the arguments and the result is necessary and dmd doesn't
> have a virtual machine, does it?
> One could try to fake the latter by compiling to executables, but it
> would require a target specific runtime/stdlib.
>
> Overall I don't have too much performance issues with CTFE.
>
> I've more issues with badly scaling compiler algorithms now that they
> are used with magnitudes bigger input, i.e. unrolled loops or huge array
> literals.
> Especially considering that they performance impact mostly stems from
> codegen
> and sometime the generated code is only used for compile time
> initialization.
>
> A lot of garbage is created during CTFE as in-place changes don't always
> work.
> For example I haven't yet succeeded in writing an in-place CTFE quicksort,
> so I ended up with 'sort(left) ~ pivot ~ sort(right)'.
>
> martin



More information about the Digitalmars-d mailing list