On Monday, 9 May 2016 at 18:19:53 UTC, David Nadlinger wrote:
Hi Stefan,

On Monday, 9 May 2016 at 16:57:39 UTC, Stefan Koch wrote:
My Plan is as follows.

I think you guys talked about it at the conference, but be sure to coordinate with Timon Gehr. You'll want to steal all the best ideas from the various implementations anyway. ;)

Do Dataflow analysis on the code that is to be ctfe'd so we can tell beforehand if we need to store state in the ctfe stack or not.

Or baring proper data-flow analysis: RefCouting the variables on the ctfe-stack could also be a solution.

I presume by "store state" you mean persisting objects beyond the bounds of a single CTFE invocation? My first inclination here would simply be to make all allocations from a new arena each time CTFE is entered (can also re-use memory from prior runs for that), do a deep-copy of the result (converting it to full AST nodes, etc.), and then drop the entire arena. But probably you have thought of (and discarded) this already.

 — David

The current implementation stores persistent state for every ctfe incovation. While caching nothing. Not even the compiled for of a function body.
Because it cannot relax purity.
Which is why a simple while-loop from 0 to 100_000_00 can crash dmd if executed at ctfe.

Your advice is a good one. I am happy to discuss with others!
There is no need to duplicate mental workload.

Reply via email to