January 02, 2017 Re: CTFE Status | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | On Monday, 2 January 2017 at 19:01:43 UTC, Stefan Koch wrote:
> On Monday, 2 January 2017 at 18:40:44 UTC, Stefan Koch wrote:
>> So guys.
>>
>> basic function-calls are supported.
>>
>> Hell YEAH!
>
> Meaning this will compile :
>
> uint caller(uint n)
> {
> return callee(n, 2);
> }
>
> uint callee(uint a, uint b)
> {
> return a*b;
> }
>
> static assert(caller(3) == 6);
> static assert(caller(24) == 48);
>
>
> uint rfn(uint n)
> {
> if (n) return n + rfn(n-1);
> return 1;
> }
>
> pragma(msg, rfn(2000));
There's something I've been wondering about. NewCTFE is basically just another backend, right? Does this mean that you'll have to implement various optimizations such as tail-call elision independently from what DMD with the default backend currently does?
|
January 02, 2017 Re: CTFE Status | ||||
---|---|---|---|---|
| ||||
Posted in reply to Meta | On Monday, 2 January 2017 at 21:52:05 UTC, Meta wrote:
>
> There's something I've been wondering about. NewCTFE is basically just another backend, right? Does this mean that you'll have to implement various optimizations such as tail-call elision independently from what DMD with the default backend currently does?
Yes, I could borrow analysis passes from dmd however to check if the optimization is applicable.
However I do not intend to do so.
CTFE is mostly used for small one-shot things.
There is no point in eliding calls.
Executing the code as soon as possible is often faster then doing the optimization.
|
January 02, 2017 Re: CTFE Status | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | On Monday, 2 January 2017 at 18:40:44 UTC, Stefan Koch wrote:
> Hell YEAH!
Nice work.
|
January 03, 2017 Re: CTFE Status | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | Hi Guys, I just enabled the handling for with(Type). makes the following code work : import core.time; import core.sys.linux.time; auto _posixClock(ClockType clockType) { with(ClockType) final switch(clockType) { case bootTime: return CLOCK_BOOTTIME; case coarse: return CLOCK_MONOTONIC_COARSE; case normal: return CLOCK_MONOTONIC; case precise: return CLOCK_MONOTONIC; case processCPUTime: return CLOCK_PROCESS_CPUTIME_ID; case raw: return CLOCK_MONOTONIC_RAW; case threadCPUTime: return CLOCK_THREAD_CPUTIME_ID; case second: assert(0); } } static assert(_posixClock(ClockType.bootTime) == CLOCK_BOOTTIME); |
January 05, 2017 Re: CTFE Status | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | On Monday, 2 January 2017 at 18:40:44 UTC, Stefan Koch wrote:
> So guys.
>
> basic function-calls are supported.
>
> Hell YEAH!
Disabled for now. Since it pushes some buffers/caches to their limit. A more flexible solution is needed.
However the good news is that the ABI seems to work better than expected.
Now it's time to deal with this-pointers and method calls.
After remaining issues with nested switches have to be fixed.
|
January 09, 2017 Re: CTFE Status | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | On Thursday, 5 January 2017 at 06:04:00 UTC, Stefan Koch wrote:
> On Monday, 2 January 2017 at 18:40:44 UTC, Stefan Koch wrote:
>> So guys.
>>
>> basic function-calls are supported.
>>
>> Hell YEAH!
>
> Disabled for now. Since it pushes some buffers/caches to their limit. A more flexible solution is needed.
This is now fixed by simply extending the limits.
Now more failures start to show and more manual bailouts are required again.
Although, I expected this to happen it bums me. :(
|
January 10, 2017 Re: CTFE Status | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | I have fixed a few bugs in the handling of casts. And fixed an oversight which would cause Xors to bailout. However Phobos-unittests are still regressed. I am now working on Method-Calls or member-function-calls. |
January 16, 2017 Re: CTFE Status | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | On Thursday, 5 January 2017 at 06:04:00 UTC, Stefan Koch wrote:
> On Monday, 2 January 2017 at 18:40:44 UTC, Stefan Koch wrote:
>> So guys.
>>
>> basic function-calls are supported.
>>
>> Hell YEAH!
>
> Disabled for now. Since it pushes some buffers/caches to their limit. A more flexible solution is needed.
> However the good news is that the ABI seems to work better than expected.
> Now it's time to deal with this-pointers and method calls.
>
> After remaining issues with nested switches have to be fixed.
Basic Function call support reenabled.
Phobos unittests pass.
|
January 16, 2017 Re: CTFE Status | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | On Monday, 16 January 2017 at 16:31:25 UTC, Stefan Koch wrote:
> Basic Function call support reenabled.
> Phobos unittests pass.
Nice!
|
January 17, 2017 Re: CTFE Status | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | On Monday, 16 January 2017 at 16:31:25 UTC, Stefan Koch wrote:
> On Thursday, 5 January 2017 at 06:04:00 UTC, Stefan Koch wrote:
>> On Monday, 2 January 2017 at 18:40:44 UTC, Stefan Koch wrote:
>>> So guys.
>>>
>>> basic function-calls are supported.
>>>
>>> Hell YEAH!
>>
>> Disabled for now. Since it pushes some buffers/caches to their limit. A more flexible solution is needed.
>> However the good news is that the ABI seems to work better than expected.
>> Now it's time to deal with this-pointers and method calls.
>>
>> After remaining issues with nested switches have to be fixed.
>
> Basic Function call support reenabled.
> Phobos unittests pass.
Just found a bug with recursive functions, which is now fixed.
So time for some perf:
-- t.d
uint rfn(uint n)
{
if (n > 2) return n + rfn(n-1) + rfn(n-2);
return 1;
}
pragma(msg, rfn(30));
--
uplink@uplink-pc:~/d/dmd$ time src/dmd t.d -c
4674396u
real 0m0.396s
user 0m0.392s
sys 0m0.000s
uplink@uplink-pc:~/d/dmd$ time dmd t.d -c
4674396u
real 0m1.993s
user 0m1.872s
sys 0m0.120s
|
Copyright © 1999-2021 by the D Language Foundation