On Saturday, 26 August 2017 at 16:52:36 UTC, Cecil Ward wrote:
I have a pure function that has constant inputs, known at
compile-time, contains no funny stuff internally - looked at
the generated code, and no RTL calls at all. But in a test call
with constant literal values (arrays initialised to literal)
passed to the pure routine GDC refuses to CTFE the whole thing,
as I would expect it (based on previous experience with d and
GDC) to simply generate a trivial function that puts out a
block of CTFE-evaluated constant data corresponding to the
input.
Unfortunately it's a bit too long to post in here. I've tried
lots of variations. Function is marked nogc safe pure nothrow
Any ideas as to why GDC might just refuse to do CTFE on
compile-time-known inputs in a truly pure situation? Haven't
tried DMD yet. Can try LDC. Am using d.godbolt.org to look at
the result, as I don't have a machine here to run a d compiler
on.
Other things I can think of. Contains function-in-a-function
calls, which are all unlined out in the generated code nicely,
and not the first time I've done that with GDC either.
Switches: Am using -Os or -O2 or -O3 - tried all. Tuning to
presume + enable the latest x86-64 instructions. release build,
no bounds-checks.
I will henceforth use the enum trick advice all times.
I noticed that the problem with init =void is compiler-dependent.
Using an enum for real CTFE, I don't get error messages from LDC
or GDC (i.e. [old?] versions currently up on d.godbolt.org) x64
compilers even if I do use the =void optimisation. This saved a
totally wasteful and pointless zero-fill of 64 bytes using 2 YMM
instructions in the particular unit test case I had, but of
course could easily be dramatically bad news depending on the
array size I am unnecessarily filling.
