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.
