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.
