February 17, 2017
On Friday, 17 February 2017 at 21:01:33 UTC, Dmitry Olshansky wrote:
>
> This is a common misconception. LLVM as AoT optimizing compiler is great, but for the JIT compiler it's actually far too slow at codegen to be a sensible choice.

I don't know how big of a misconception it is. The Dropbox effort on Pyston (LLVM JIT for Python) just recently shut down and nobody expressed a lot of surprise in the HN comments.
February 17, 2017
On 2/17/17 10:37 PM, jmh530 wrote:
> On Friday, 17 February 2017 at 21:01:33 UTC, Dmitry Olshansky wrote:
>>
>> This is a common misconception. LLVM as AoT optimizing compiler is
>> great, but for the JIT compiler it's actually far too slow at codegen
>> to be a sensible choice.
>
> I don't know how big of a misconception it is. The Dropbox effort on
> Pyston (LLVM JIT for Python) just recently shut down and nobody
> expressed a lot of surprise in the HN comments.

It might be that HN just in general are pessimistic ;)
w.r.t Pyston I've seen it coming since the very first blog post that described their approach to the problem. However I've seen lots of folks being quite enthusiastic about that effort.

----
Dmitry Olshansky
February 18, 2017
Will be possible to make precompiled headers and distribute it with static library for example?
February 18, 2017
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> Hi Guys, due to the old CTFE status thread getting to page 30, I am now starting a new one.
>
> [...]

Thank you for your continued work on this. I heavily rely on D's CTFE functionality and I try to read all your updates on it.
February 19, 2017
On Saturday, 18 February 2017 at 22:40:44 UTC, Moritz Maxeiner wrote:
> On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
>> Hi Guys, due to the old CTFE status thread getting to page 30, I am now starting a new one.
>>
>> [...]
>
> Thank you for your continued work on this. I heavily rely on D's CTFE functionality and I try to read all your updates on it.

Hello Moritz,
D's ctfe functionality is almost complete.
This thread is not about ctfe as it is currently implemented.
I am working on/writing about a faster re-implementation of ctfe.

When my work is finished nothing will change functionality wise, it will just be much more efficient.
February 19, 2017
On Sunday, 19 February 2017 at 01:52:07 UTC, Stefan Koch wrote:
> On Saturday, 18 February 2017 at 22:40:44 UTC, Moritz Maxeiner wrote:
>> On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
>>> Hi Guys, due to the old CTFE status thread getting to page 30, I am now starting a new one.
>>>
>>> [...]
>>
>> Thank you for your continued work on this. I heavily rely on D's CTFE functionality and I try to read all your updates on it.
>
> Hello Moritz,
> D's ctfe functionality is almost complete.
> This thread is not about ctfe as it is currently implemented.
> I am working on/writing about a faster re-implementation of ctfe.
>
> When my work is finished nothing will change functionality wise, it will just be much more efficient.

Hello Stefan,
my apologies if I wasn't clear: I'm aware that this isn't about adding anything new in terms of functionality, what I intended to imply with "heavily rely on" was that I use enough of it for it to be noticeable in compile time / memory consumption, which is why I'm very happy about potential speedup and/or memory consumption reduction in CTFE. One public example of that was llvm-d <2.0.
February 19, 2017
On Saturday, 18 February 2017 at 21:24:18 UTC, Satoshi wrote:
> Will be possible to make precompiled headers and distribute it with static library for example?

anything is possible with ctfe and mixins and templates.
certainly header generation as well, you can write your own system for it and do it as a build step, in case the built-in header generator is inadequate.
February 21, 2017
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:

>
> Currently I am having trouble caused by a bug in dmds inliner that only happens on when dmd is compiled as a 32bit executable until I have  isolated / fixed this development is slowed down.

I am slowly narrowing down on the source  of this bug.
Until it is fixed builds of newCTFE might not behave correctly, if they have been complied with -inline!



February 21, 2017
On Tuesday, 21 February 2017 at 01:57:21 UTC, Stefan Koch wrote:
> On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
>
>>
>> Currently I am having trouble caused by a bug in dmds inliner that only happens on when dmd is compiled as a 32bit executable until I have  isolated / fixed this development is slowed down.
>
> I am slowly narrowing down on the source  of this bug.
> Until it is fixed builds of newCTFE might not behave correctly, if they have been complied with -inline!

The culprit that introduced the bug seems to be :
 https://github.com/dlang/dmd/commit/cd01efb4dd5e32277cb156c3cc2b451bdcb68b52

however more testing is needed before I can be sure.

February 25, 2017
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:

> Currently I am having trouble caused by a bug in dmds inliner that only happens on when dmd is compiled as a 32bit executable until I have  isolated / fixed this development is slowed down.

This bug was Issue #17220 and is fixed ~master.
Unitl the auto-tester is updated is updated workarounds have to suffice.
In this case the workaround is padding a structure such that it's size in no longer 32.