Migrating an existing more modern GC to D's gc.d

[H. S. Teoh]

On Sat, Apr 14, 2018 at 01:40:58AM +0200, Timon Gehr via Digitalmars-d wrote:
> On 13.04.2018 23:40, Jonathan M Davis wrote:
> > On Friday, April 13, 2018 22:36:31 Timon Gehr via Digitalmars-d wrote:
> > > On 10.04.2018 10:56, Jonathan M Davis wrote:
> > > > CTFE only ever happens when it must happen. The compiler never
> > > > does it as an optimization.
> > > 
> > > The frontend doesn't. The backend might.
> > 
> > The optimizer may do constant folding or inline the code so far that
> > it just gives the result, but it doesn't do actual CTFE. That's all
> > in the frontend.
> > 
> > - Jonathan M Davis
> > 
> 
> CTFE just stands for "compile-time function evaluation". Claiming that
> the compiler never does this as an optimization is a bit misleading,
> but fine.

CTFE, as currently implemented in the compiler front-end (i.e., common
across dmd, gdc, ldc), is actually only invoked when a value is
*required* at compile-time, e.g., as a template argument or enum.  While
the CTFE code did grow out of the constant-folding code, the two are
actually distinct, and the front-end never calls CTFE when performing
constant-folding (even though CTFE could be construed to be a souped-up
form of constant-folding).  This is a rather fine distinction in the
current implementation that I wasn't aware of until recently.

Certain backends, like ldc's, may also perform their own "compile-time
function evaluation", e.g., on the LLVM IR, as part of their
optimization pass.  For example, the LDC optimizer can literally execute
LLVM IR at compile-time and replace an entire function-call tree with a
single instruction that loads the computed value as a literal.  This has
nothing to do with CTFE (as we know it in D) per se, but is a feature of
the LDC optimizer.


T

-- 
It only takes one twig to burn down a forest.