newCTFE Status August 2019

The main addition was enriched internal debug data.
Now newCTFE can emit proper dwarf source_locations which used with the gccjit backend.
This means given you use the gccjit-backend for newCTFE you can (step through!) ctfe-code.
At least in theory ... in reality some of the time there will not be source code for you to step through, (think mixins).

Another rather important bugfix was done the handling of for loops, it turned out that for loops without increment statement would not properly behave when `continue` was encountered (they'd jump to the end of the loop instead of the beginning).

There are currently 2 main bugs still to be fixed:
- 1. floating point corner cases
- 2. wrong code on indirections inside closures.

It should be noted that I just spent the better part of a week working on the aforementioned 2 issues, and it does not look like they'll be fixed soon.

That said, I am hopeful to be able to release newCTFE in 2020!

My Thanks to everyone in this forum who encouraged me.

Also a special thanks to Johnathan Blow, who's occasional streams on Jai's progress led me to pick up the newCTFE torch again!

Cheers,

Stefan

P.S. the current newCTFE patch has about 17000 additional lines.
10700 of which are actual interpreter and test-code, and the rest are internal testcases, alternative back-ends (LLVM/GCCJIT/C/IR-Printer).

Re-basing to newer versions of the compiler will be done once the dmd/druntime/phobos test-suites and my internal tests are passing.

On Thu, Aug 15, 2019 at 09:42:47PM +0000, Stefan Koch via Digitalmars-d wrote: > Hi Guys, > > I had 2 weeks of vacation recently, and I used them to work on newCTFE again. Yes!!! [...] > That said, I am hopeful to be able to release newCTFE in 2020! *celebratory dance* > My Thanks to everyone in this forum who encouraged me. > > Also a special thanks to Johnathan Blow, who's occasional streams on Jai's progress led me to pick up the newCTFE torch again! [...] Go, Stefan, go! Bring newCTFE into a reality! D badly needs this. Non-trivial CTFE is what D can do that no other language I know can. Right now it's seriously hampered by lackluster speed and memory usage; newCTFE can turn this into a huge game-changer. T -- Do not reason with the unreasonable; you lose by definition.

On Thursday, 15 August 2019 at 21:42:47 UTC, Stefan Koch wrote: > Hi Guys, > > I had 2 weeks of vacation recently, and I used them to work on newCTFE again. Nice to see that you keep the ball rolling! […] > It should be noted that I just spent the better part of a week working on the aforementioned 2 issues, and it does not look like they'll be fixed soon. Last time you told me about that other difficult issue, you were able to fix it shortly after. So who knows, maybe you will get a similar breakthrough soon. > That said, I am hopeful to be able to release newCTFE in 2020! That would be great! > My Thanks to everyone in this forum who encouraged me. > > Also a special thanks to Johnathan Blow, who's occasional streams on Jai's progress led me to pick up the newCTFE torch again! Interesting… Keep having fun, Bastiaan.

On Thursday, 15 August 2019 at 21:42:47 UTC, Stefan Koch wrote: > P.S. the current newCTFE patch has about 17000 additional lines. > 10700 of which are actual interpreter and test-code, and the rest are internal testcases, alternative back-ends (LLVM/GCCJIT/C/IR-Printer). > > Re-basing to newer versions of the compiler will be done once the dmd/druntime/phobos test-suites and my internal tests are passing. Are you developing this out in the open or are you keeping the code closer to your chest until you are done? Both are fine with me. I'm mostly curious. Keep up the good work! You have taken on a beast of a spare time project!

On Sunday, 18 August 2019 at 22:18:29 UTC, Gregor Mückl wrote: > Are you developing this out in the open or are you keeping the code closer to your chest until you are done? These branches have been recently updated: https://github.com/UplinkCoder/dmd/tree/newCTFE_reboot_20741 https://github.com/UplinkCoder/dmd/tree/newCTFE_reboot_20741_gccjit

On Thursday, 15 August 2019 at 21:42:47 UTC, Stefan Koch wrote: > > That said, I am hopeful to be able to release newCTFE in 2020! > Can't wait! We'll be able to make a lot more parsing at compile-time :)

On Monday, 19 August 2019 at 13:37:18 UTC, Guillaume Piolat wrote: > Can't wait! We'll be able to make a lot more parsing at compile-time :) My compiles are already at 8GB memory usage thanks to CTFE. Even just a patch to fix array memory handling behind the scenes would be great. But newCTFE would certainly be the preferred option.

On 8/19/2019 7:02 AM, Ethan wrote: > Even just a patch to fix array memory handling behind the scenes would be great. The memory handling could be fixed if the CTFE's allocated AST's were all allocated from a separate pool, and marked as such. Then, the returned AST from CTFE can be scanned and every marked node replaced. Then, the entire pool can be discarded. Should be fairly simple to implement.

On Monday, 19 August 2019 at 23:04:23 UTC, Walter Bright wrote: > On 8/19/2019 7:02 AM, Ethan wrote: >> Even just a patch to fix array memory handling behind the scenes would be great. > > The memory handling could be fixed if the CTFE's allocated AST's were all allocated from a separate pool, and marked as such. Then, the returned AST from CTFE can be scanned and every marked node replaced. Then, the entire pool can be discarded. > > Should be fairly simple to implement. Replying to this to keep the topic on top! That's an amazing outcome! What would be also, IYUO, the expected impact on speed performance? /Paolo

Forums