March 18, 2017 Re: CTFE Status 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> [ ... ]
Small update I fixed the handling of $ in slices.
[1,2,3,4][$-2 .. $] == [3,4]
will now work in newCTFE
|
March 17, 2017 Re: CTFE Status 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | On Sat, Mar 18, 2017 at 03:29:15AM +0000, Stefan Koch via Digitalmars-d wrote: > On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote: > > [ ... ] > > Small update I fixed the handling of $ in slices. > [1,2,3,4][$-2 .. $] == [3,4] > will now work in newCTFE Awesome! It's great to see the new CTFE engine slowly but surely taking shape. Really looking forward to see the final product. T -- The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- Anonymous |
March 19, 2017 Re: CTFE Status 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> [ ... ]
I just restored Array/Slice-Expansion.
I also introduced concat!
This will now compile with newCTFE!
static immutable uint[] OneToTen = [1,2,3,4,5,6,7,8,9,10];
const(uint[]) SliceOf1to10(uint lwr, uint upr)
{
return OneToTen[lwr .. upr];
}
const(uint)[] testConcat()
{
return SliceOf1to10(0,4) ~ SliceOf1to10(7,9);
}
static assert(testConcat == [1,2,3,4,8,9]);
|
March 20, 2017 Re: CTFE Status 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> [ ... ]
Oh darn, function pointers regressed!
I did not notice because the corresponding tests were commented out.
I am working to fix it ASAP.
|
March 20, 2017 Re: CTFE Status 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | On Monday, 20 March 2017 at 11:48:56 UTC, Stefan Koch wrote:
> On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
>> [ ... ]
>
> Oh darn, function pointers regressed!
> I did not notice because the corresponding tests were commented out.
>
> I am working to fix it ASAP.
It's not function pointers.
It's slice extension.
It just happened that my function pointer tests relied on slice extension working.
|
March 20, 2017 Re: CTFE Status 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | On Monday, 20 March 2017 at 12:06:57 UTC, Stefan Koch wrote:
> On Monday, 20 March 2017 at 11:48:56 UTC, Stefan Koch wrote:
>> On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
>>> [ ... ]
>>
>> Oh darn, function pointers regressed!
>> I did not notice because the corresponding tests were commented out.
>>
>> I am working to fix it ASAP.
>
> It's not function pointers.
> It's slice extension.
>
> It just happened that my function pointer tests relied on slice extension working.
Actually it's just local variables of slices :)
Doged a nasty bullet there.
|
March 21, 2017 Re: CTFE Status 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> [ ... ]
Hi I fixed the local slice issue.
It turned out that there was special code in place to deal with this case;
But that I forgot to change that to the new slice ABI.
The moral of this story is;
ABI changes are hard to do if you have an ad-hoc approach to it.
However now I made ABI-dependeant values more visible.
And it is unlikely that further slice-ABI changes will cause problems.
Cheers,
Stefan
|
March 22, 2017 Re: CTFE Status 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> [ ... ]
I just fixed a bug in switches, where the fall-trough case would incorrectly jump after the switch.
The reason this bug occurred is that none of my tests did cover the fall-trough case.
The code that handles switches converts them into a big if-else chain because jump-tables are usually more expensive for small switches.
|
March 31, 2017 Re: CTFE Status 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> [ ... ]
Alright guys.
I am just fixing the newCTFE LLVM backend such that I can have better guesses as to what performance a JIT could archive.
Due to the ABI changes the llvm-backend a little optimization potential.
It'll be a while until the llvm backend is on par again.
Because functions and such need to be dealt with quite differently.
Also the llvm backend recives less testing since I cannot run it at compile time(Yet :))
Cheers,
Stefan
--
sorry for the short message I am busy fixing codegen bugs as always.
|
March 31, 2017 Re: CTFE Status 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | On Friday, 31 March 2017 at 14:05:00 UTC, Stefan Koch wrote: > On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote: >> [ ... ] > > Alright guys. > > I am just fixing the newCTFE LLVM backend such that I can have better guesses as to what performance a JIT could archive. > > Due to the ABI changes the llvm-backend a little optimization potential. > > It'll be a while until the llvm backend is on par again. > Because functions and such need to be dealt with quite differently. > Also the llvm backend recives less testing since I cannot run it at compile time(Yet :)) > > Cheers, > Stefan > -- > sorry for the short message I am busy fixing codegen bugs as always. oh, yeah ... If you want to checkout the llvm backend fethc the newCTFE_LLVMBackend branch from https://github.com/UplinkCoder/dmd. the posix.mak is hardcoded to use libLLVM-3.5. However you should be able to use any version newer then 3.3. |
Copyright © 1999-2021 by the D Language Foundation