Battle-plan for CTFE
David Nadlinger via Digitalmars-d-announce
digitalmars-d-announce at puremagic.com
Mon May 9 11:19:53 PDT 2016
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
More information about the Digitalmars-d-announce
mailing list