No CTFE of function

[Cecil Ward via Digitalmars-d-learn]

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.