On Tuesday, 24 January 2017 at 15:33:37 UTC, Stefan Koch wrote:
> The lookup time is one issue but not the most important,
> The instanciation of a template is a non-trivial operation within the compiler.
> Type-deduction ast rewriting expression expansion
> all of that takes time and a huge chunk at that.

Interesting. Is that the major cause of high memory usage in DMD?

> Also binary code needs to be generated and that code is generated for every instance regardless of how similar they are.

Thanks.

On Tuesday, 24 January 2017 at 15:48:19 UTC, Nordlöw wrote:
> On Tuesday, 24 January 2017 at 15:33:37 UTC, Stefan Koch wrote:
>> The lookup time is one issue but not the most important,
>> The instanciation of a template is a non-trivial operation within the compiler.
>> Type-deduction ast rewriting expression expansion
>> all of that takes time and a huge chunk at that.
>
> Interesting. Is that the major cause of high memory usage in DMD?
>
>> Also binary code needs to be generated and that code is generated for every instance regardless of how similar they are.
>
> Thanks.

I would have to investigate the specific case.
It's also because the recursive nature of templates that you end up with +100_000 instances

It those numbers even small allocations have a huge impact.

On Tuesday, 24 January 2017 at 09:52:13 UTC, Stefan Koch wrote:
> NEW CTFE IS GREEN ON 64 BIT!
> GREEN!


I just fixed a regression found by compiling vibe.d.
We are now even greener!

On Tuesday, 24 January 2017 at 06:35:56 UTC, Stefan Koch wrote:
> The blacklisted functions are now down to only two.
>
> Those are the bitswap function in druntime.
> Because the interpreter does handle all values as 64bit internally it tends to miscompile code that uses xor on 32bit values.
>
> And the second one is the "to" template from std.conv;
> Because of the aforementioned UTF issues.
>
> NOTE: that the blacklist is by nature transitive meaning a function that calls a blacklisted function will also not be interpreted by newCTFE

The blacklisting of bitswap was removed, because we now bailout on bit-level operations on 32bit values.

However I did have to add a unittest-specific bailout for fail_compilation/fail14304.d
which requires the ctfe interpeter to detect a semantically invalid situation that should have been detected before we ever begin ctfe.

newCTFE is green now on all platforms!

On Wednesday, 25 January 2017 at 12:36:02 UTC, Stefan Koch wrote:
> newCTFE is green now on all platforms!

<3

On Wednesday, 25 January 2017 at 12:36:02 UTC, Stefan Koch wrote:
> newCTFE is green now on all platforms!

Congrats.

How much work remains?

On Wednesday, 25 January 2017 at 15:26:39 UTC, jmh530 wrote:
> On Wednesday, 25 January 2017 at 12:36:02 UTC, Stefan Koch wrote:
>> newCTFE is green now on all platforms!
>
> Congrats.
>
> How much work remains?

Quite a lot.

- Slicing
- Appending
- ||
- String support (implying utf conversions)
- Floating-Point

- classes
- exceptions
- function pointers
- closures

and

proper handling of more complex types
such as arrays of structures

On Wednesday, 25 January 2017 at 12:36:02 UTC, Stefan Koch wrote:
> newCTFE is green now on all platforms!

Great!

On Wednesday, 25 January 2017 at 12:36:02 UTC, Stefan Koch wrote:
> newCTFE is green now on all platforms!

I just found an interesting bug just now.
The following code would cause newCTFE to segfault.

char* initPtr()
{
    return cast(char*) size_t.max;
}

static assert(cast(size_t)initPtr() == size_t.max);

Because it would try to return the char-value at heap-address size_t.max;
newCTFE allocates a 16MB heap by default and therefore the address was hopelessly out-of-bounds.

The reason this was not detected before is because:
  `cast(char*) size_t.max;`
does not actually produce a cast expression.
But rather an IntegerLiteral with the type char*.

After dealing with dmd for 7 months, I could figure out this bug in a day.
If I had run into this earlier I would have been stuck for weeks :)