July 17, 2017 Re: newCTFE Status July 2017 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | On Sunday, 16 July 2017 at 10:41:56 UTC, Stefan Koch wrote:
> On Saturday, 15 July 2017 at 21:35:30 UTC, Tourist wrote:
>>
>> Nice, but it's not as clear, and doesn't specify what's left to be done.
>
> features left to be done are:
>
> - && and ||
> - multi-dimensional slices/arrays
> - associative arrays
> - complex structs
> - classes
> - unions
> - unicode support.
You could start next month's thread with features implemented and then this list of features remaining.
|
July 17, 2017 Re: newCTFE Status July 2017 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | On Thursday, 13 July 2017 at 12:45:19 UTC, Stefan Koch wrote: > [ ... ] I just figured out the bug in test/runnable/template8.d What happens somewhere inside those templates is that the following expression is executed: "some string literal" ~ null; when then happens we executed the equivalent of the following in bytecode { size_t lhsorrhs = lhs | rhs; if (!lhsorrhs) return null; // needed to handle the special case null ~ null == null; immutable elemSize = elementSize(lhs); // can be assumed to be the same as rhs // sema would have complained otherwise int newSize = 0; int lhsSize = lhs ? getLength(lhs) * elemSize : 0; int rhsSize = rhs ? getLength(rhs) * elemSize : 0; newSize += lhsSize; newSize += (getLength(rhs) * elemSize); void* newString = allocateHeap(newSize + SliceDescriptor.sizeof); auto sliceDesc = cast(SliceDescriptor*) newString; sliceDesc.base = newString + SliceDescriptor.sizeof; sliceDesc.length = newSize / elemSize; newString += SliceDescriptor.sizeof; memcpy(newString, lhs, lhsSize); memcpy(newString + lhsSize, rhs, rhsSize); } now what happens if either lhs OR rhs are null but not both ? right a null pointer dereference. and this is what happend here. Why did it take so long to find ? Well please scan the test https://github.com/dlang/dmd/blob/master/test/runnable/template8.d yourself and tell me where you see "something" ~ null :) |
July 18, 2017 Re: newCTFE Status July 2017 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | On Thursday, 13 July 2017 at 12:45:19 UTC, Stefan Koch wrote: > [ ... ] Hi Guys, I have good news and bad news. The good news: newCTFE just compiled my own version of std.bitmanip.bitfields dubbed fastFields. which can be seen here: https://gist.github.com/UplinkCoder/b3501425a4fb4992c6cf1c77d6c3638a The bad news: It miscompiles it. The generated code is bogus :) Fixing this could take a while. Because even with my improved debugging tools it's still over 3k of instructions to look through. It does not help that over 300 temporaries are allocated. -- Stefan |
July 18, 2017 Re: newCTFE Status July 2017 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | On Tue, Jul 18, 2017 at 07:08:49PM +0000, Stefan Koch via Digitalmars-d wrote: [...] > The bad news: > It miscompiles it. > > The generated code is bogus :) > > Fixing this could take a while. > Because even with my improved debugging tools it's still over 3k of > instructions to look through. > > It does not help that over 300 temporaries are allocated. [...] Shouldn't there be a way to reduce the test case so that you don't have to look through 300 temporaries? T -- Valentine's Day: an occasion for florists to reach into the wallets of nominal lovers in dire need of being reminded to profess their hypothetical love for their long-forgotten. |
July 18, 2017 Re: newCTFE Status July 2017 | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | On Tuesday, 18 July 2017 at 19:11:37 UTC, H. S. Teoh wrote:
>
> Shouldn't there be a way to reduce the test case so that you don't have to look through 300 temporaries?
>
Yes.
However, there is not automated way to reduce it.
So to find the source-code which actually leads to the mis-compiled part.
I still have to consider an awful lot of code :)
|
July 18, 2017 Re: newCTFE Status July 2017 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | On Tuesday, 18 July 2017 at 19:23:56 UTC, Stefan Koch wrote: > On Tuesday, 18 July 2017 at 19:11:37 UTC, H. S. Teoh wrote: >> >> Shouldn't there be a way to reduce the test case so that you don't have to look through 300 temporaries? >> > Yes. > However, there is not automated way to reduce it. > So to find the source-code which actually leads to the mis-compiled part. > I still have to consider an awful lot of code :) Why can't you use DustMite? It's an amazing tool! https://github.com/CyberShadow/DustMite/wiki |
July 20, 2017 Re: newCTFE Status July 2017 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | On Thursday, 13 July 2017 at 12:45:19 UTC, Stefan Koch wrote:
> [ ... ]
Hi Guys,
The following code compiles now and runs in very reasonable time even for unreasonable repeat-counts.
string repeatString(string s, uint repeatCount)
{
char[] result;
uint sLength = cast(uint) s.length;
result.length = sLength * repeatCount;
uint p1 = 0;
uint p2 = sLength;
foreach(rc;0 .. repeatCount)
{
result[p1 .. p2] = s[0 .. sLength];
p1 += sLength;
p2 += sLength;
}
return cast(string) result;
}
Note: a version that uses `result ~= s` runs much much slower and will soon run out of the 16M heapMemory.
static assert(
"o_o ".repeatString(24) ==
`o_o o_o o_o o_o o_o o_o o_o o_o o_o o_o o_o o_o o_o o_o o_o o_o o_o o_o o_o o_o o_o o_o o_o o_o `
);
|
July 22, 2017 Re: newCTFE Status July 2017 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | On Thursday, 13 July 2017 at 12:45:19 UTC, Stefan Koch wrote:
> [ ... ]
Hi Guys,
Another work-filled two day went by.
And here is the fruit of the labor:
int[2][3] split(int[6] a)
{
int[2][3] result;
foreach (i; 0 .. typeof(result[0]).length)
{
foreach (j; 0 .. result.length)
{
auto idx = i*result.length + j;
result[j][i] = a[idx];
}
}
return result;
}
static assert(split([1,2,3,4,5,6]) == [[1, 4], [2, 5], [3, 6]]);
The above code does now work at ctfe.
Meaning we are well on our way of supporting multidimensional arrays.
Multidimensional Slices however are a little tricker.
|
July 22, 2017 Re: newCTFE Status July 2017 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | On Thursday, 13 July 2017 at 12:45:19 UTC, Stefan Koch wrote:
> [ ... ]
Hi Guys,
Due to improved ABI handling a subset of slices of complex structs work now :)
The following code will correctly compile with newCTFE.
struct NA
{
string name;
uint age;
}
NA[] make5(string name)
{
NA[] result;
foreach(i; 1 .. 6)
{
string nameN = name ~ [cast(immutable char)('0' + (i % 10))];
result ~= [NA(nameN , i-1)];
}
return result;
}
static assert (make5("Tony") == [NA("Tony1", 0u), NA("Tony2", 1u), NA("Tony3", 2u), NA("Tony4", 3u), NA("Tony5", 4u)]);
As soon as the foreach-loop is iterated more then 1000 times you will see a 7-10x speed improvement :)
|
July 23, 2017 Re: newCTFE Status July 2017 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | On Thursday, 13 July 2017 at 12:45:19 UTC, Stefan Koch wrote:
> [ ... ]
Hi Guys
I am currently fixing multi-dimensional arrays as outer parameters.
So the following does not work.
uint sumXd(uint[2][2]) { ... bla bla ... }
pragma(msg, sumXd([[2,4],[4,7]]));
This pretty tricky since we have the constraint of reprenting slices and arrays with the same ABI.
So far I have worked 15 hours on this issue and it looks like it's going to be alot more :(
|
Copyright © 1999-2021 by the D Language Foundation