On Thursday, 15 December 2016 at 23:05:55 UTC, Dmitry Olshansky wrote:
>
> Afaik string switches are implemented as a fairly slow hash table. Optimal solutions like building a trie would be a nice enhancement.
>
> ---
> Dmitry Olshansky

Tries take up alot of memory for sparse tables.
I would like to avoid them.

Futhermore, CTFE is targeted towards smaller functions with low iteration count.
Therefore producing bytecode as fast as possible is priority.

This function from std.uri does now compile and execute correctly.
private enum
{
    URI_Alpha = 1,
    URI_Reserved = 2,
    URI_Mark = 4,
    URI_Digit = 8,
    URI_Hash = 0x10,        // '#'
}

immutable ubyte[128] uri_flags =      // indexed by character
    ({
        ubyte[128] uflags;

        // Compile time initialize
        uflags['#'] |= URI_Hash;

        foreach (c; 'A' .. 'Z' + 1)
        {
            uflags[c] |= URI_Alpha;
            uflags[c + 0x20] |= URI_Alpha;   // lowercase letters
        }
        foreach (c; '0' .. '9' + 1) uflags[c] |= URI_Digit;
        foreach (c; ";/?:@&=+$,")   uflags[c] |= URI_Reserved;
        foreach (c; "-_.!~*'()")    uflags[c] |= URI_Mark;
        return uflags;
})();

I have to say I was surprised myself :)
It takes around 30 us to execute, which can be improved for sure :)

On Thursday, 15 December 2016 at 23:37:50 UTC, Stefan Koch wrote:
> On Thursday, 15 December 2016 at 23:05:55 UTC, Dmitry Olshansky wrote:
>>
>> Afaik string switches are implemented as a fairly slow hash table. Optimal solutions like building a trie would be a nice enhancement.
>>
>> ---
>> Dmitry Olshansky
>
> Tries take up alot of memory for sparse tables.
> I would like to avoid them.
>
> Futhermore, CTFE is targeted towards smaller functions with low iteration count.
> Therefore producing bytecode as fast as possible is priority.
>
> This function from std.uri does now compile and execute correctly.
> private enum
> {
>     URI_Alpha = 1,
>     URI_Reserved = 2,
>     URI_Mark = 4,
>     URI_Digit = 8,
>     URI_Hash = 0x10,        // '#'
> }
>
> immutable ubyte[128] uri_flags =      // indexed by character
>     ({
>         ubyte[128] uflags;
>
>         // Compile time initialize
>         uflags['#'] |= URI_Hash;
>
>         foreach (c; 'A' .. 'Z' + 1)
>         {
>             uflags[c] |= URI_Alpha;
>             uflags[c + 0x20] |= URI_Alpha;   // lowercase letters
>         }
>         foreach (c; '0' .. '9' + 1) uflags[c] |= URI_Digit;
>         foreach (c; ";/?:@&=+$,")   uflags[c] |= URI_Reserved;
>         foreach (c; "-_.!~*'()")    uflags[c] |= URI_Mark;
>         return uflags;
> })();
>
> I have to say I was surprised myself :)
> It takes around 30 us to execute, which can be improved for sure :)

Hey Guys, I just had a mental breakthrough in regards to handling doubly in-directed read-modify-write operations.
such as changing the length of an array through a pointer.
Refernce values will carry a typed pointer to their origin thereby allowing them to be treated like normal values most of the time, and only receive special treatment on assignment.
(Which is where they have to emit a Store32 Instead of a Set)
As this has design implications, I will resolve this  before continuing function-call support.
In fact, I think I will have to delay call support until most of the ABI issues are worked out.

Hey Guys bad news, Regressions.
The handling of default constructed Struct-Literals inside of newCTFE is broken.

I have no idea were this came from all of a sudden.
I was in crunch-mode to get the phobos unittest to compile, I don't remember the last 72 hours at all :)
So it might take a while until the regression is resolved.
I apologize for the inconvenience.

On Friday, 16 December 2016 at 09:32:13 UTC, Stefan Koch wrote:
> Hey Guys bad news, Regressions.
> The handling of default constructed Struct-Literals inside of newCTFE is broken.
>
> I have no idea were this came from all of a sudden.
> I was in crunch-mode to get the phobos unittest to compile, I don't remember the last 72 hours at all :)
> So it might take a while until the regression is resolved.
> I apologize for the inconvenience.

Apparently the regression was introduce in
I confirmed that the regression was introduced in
https://github.com/dlang/dmd/pull/6186/commits/33dbf5aee7d42b1929fd62ef176bd299c4da8ac5

Which suggests that it only worked by chance before :(

On Friday, 16 December 2016 at 10:26:15 UTC, Stefan Koch wrote:
> On Friday, 16 December 2016 at 09:32:13 UTC, Stefan Koch wrote:
>> Hey Guys bad news, Regressions.
>> The handling of default constructed Struct-Literals inside of newCTFE is broken.
>>
>> I have no idea were this came from all of a sudden.
>> I was in crunch-mode to get the phobos unittest to compile, I don't remember the last 72 hours at all :)
>> So it might take a while until the regression is resolved.
>> I apologize for the inconvenience.
>
> Apparently the regression was introduce in
> I confirmed that the regression was introduced in
> https://github.com/dlang/dmd/pull/6186/commits/33dbf5aee7d42b1929fd62ef176bd299c4da8ac5
>
> Which suggests that it only worked by chance before :(

It's confirmed.
The test was not thorough enough.
The gist with the current newCTFE compatible code with  was updated.
https://gist.github.com/UplinkCoder/89faa06311e417aa93ea99bc92934d3e

On Friday, 16 December 2016 at 10:33:32 UTC, Stefan Koch wrote:
> On Friday, 16 December 2016 at 10:26:15 UTC, Stefan Koch wrote:
>> On Friday, 16 December 2016 at 09:32:13 UTC, Stefan Koch wrote:
>>> Hey Guys bad news, Regressions.
>>> The handling of default constructed Struct-Literals inside of newCTFE is broken.
>>>
>>> I have no idea were this came from all of a sudden.
>>> I was in crunch-mode to get the phobos unittest to compile, I don't remember the last 72 hours at all :)
>>> So it might take a while until the regression is resolved.
>>> I apologize for the inconvenience.
>>
>> Apparently the regression was introduce in
>> I confirmed that the regression was introduced in
>> https://github.com/dlang/dmd/pull/6186/commits/33dbf5aee7d42b1929fd62ef176bd299c4da8ac5
>>
>> Which suggests that it only worked by chance before :(
>
> It's confirmed.
> The test was not thorough enough.
> The gist with the current newCTFE compatible code with  was updated.
> https://gist.github.com/UplinkCoder/89faa06311e417aa93ea99bc92934d3e

Another bug is going to be fixed soon, causing infinite recursion on structs that have pointer of their own type.
This will allow me to remove a few bail-outs and compile more of phobos.

I just fixed gotos again.
While researching unusually large performance drops, I found the cause for a rather nasty bug. (It was an off-by-one error again :))

It turned out that there were circumstances where some gotos would be dropped and the corresponding fixup jumps where never emitted.

Due to a curious situation in the dmd ast, I had to make jumps without addresses into nops.
This was hiding the bug.

BTW supporting NOPS has been a huge pain for some time now.
I will look into fixing my dmd-ast handling to make them unnecessary.
Jumps that don't know where they are supposed to go should not be ignored but an error instead!

On Saturday, 17 December 2016 at 04:14:29 UTC, Stefan Koch wrote:
> I just fixed gotos again.
> While researching unusually large performance drops, I found the cause for a rather nasty bug. (It was an off-by-one error again :))
>
> It turned out that there were circumstances where some gotos would be dropped and the corresponding fixup jumps where never emitted.
>
> Due to a curious situation in the dmd ast, I had to make jumps without addresses into nops.
> This was hiding the bug.
>
> BTW supporting NOPS has been a huge pain for some time now.
> I will look into fixing my dmd-ast handling to make them unnecessary.
> Jumps that don't know where they are supposed to go should not be ignored but an error instead!

I rectified a few more performance problems.
The StringEquals macro put alot of pressure on the bytecode generator.
Therefore I implemented it as an instruction.
Interestingly this did not speed up the execution by as much as I would have expected,
maybe I need better test-cases ?

Miscompiling phobos code is down to 4 functions.
std.range.primitives.{front, empty, back}
and std.traits.defaultParameters.
Note, StructLiterals are still regressed.
I am looking into it.

On Saturday, 17 December 2016 at 08:53:07 UTC, Stefan Koch wrote:
> Miscompiling phobos code is down to 4 functions.
> std.range.primitives.{front, empty, back}
> and std.traits.defaultParameters.
> Note, StructLiterals are still regressed.
> I am looking into it.

Fixed the regression.
It was an off-by-one error in the check of the member-count.
causing the last field of a struct to be considered not part of the struct :p