January 24, 2017 Re: CTFE Status | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | 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. |
January 24, 2017 Re: CTFE Status | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nordlöw | 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.
|
January 24, 2017 Re: CTFE Status | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | 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!
|
January 25, 2017 Re: CTFE Status | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | 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.
|
January 25, 2017 Re: CTFE Status | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | newCTFE is green now on all platforms! |
January 25, 2017 Re: CTFE Status | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | On Wednesday, 25 January 2017 at 12:36:02 UTC, Stefan Koch wrote:
> newCTFE is green now on all platforms!
<3
|
January 25, 2017 Re: CTFE Status | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | 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?
|
January 25, 2017 Re: CTFE Status | ||||
---|---|---|---|---|
| ||||
Posted in reply to jmh530 | 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
|
January 25, 2017 Re: CTFE Status | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | On Wednesday, 25 January 2017 at 12:36:02 UTC, Stefan Koch wrote:
> newCTFE is green now on all platforms!
Great!
|
January 26, 2017 Re: CTFE Status | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | 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 :)
|
Copyright © 1999-2021 by the D Language Foundation