| |
![H. S. Teoh's Gravatar profile Gravatar of H. S. Teoh](//www.gravatar.com/avatar/62cf361f36fd5885c467c7f5d7d49fa4?d=identicon&s=32) | Posted by H. S. Teoh in reply to Cecil Ward | Permalink Reply |
|
H. S. Teoh ![H. S. Teoh's Gravatar profile Gravatar of H. S. Teoh](//www.gravatar.com/avatar/62cf361f36fd5885c467c7f5d7d49fa4?d=identicon&s=80)
Posted in reply to Cecil Ward
| On Sat, May 13, 2023 at 07:21:30PM +0000, Cecil Ward via Digitalmars-d wrote:
> Here’s a snippet of code which was compiled with both GDC and LDC, latest versions currently present on the godbolt Compiler Explorer site, target = x86-64, command line options -O3 -release / -frelease
>
> immutable (int)[]
> test() {
> immutable int[] s = [1];
>
> return s[1..2];
> }
>
> There is no CTFE here with either compiler, and the bug in the return statement is not spotted by the compilers at compile time. It’s clearer to see in the LDC compiler, the return value is an address off the end of the initialiser data array and a length of 1. If the compiler had CTFE’d s, had then done constant propagation and CTFE’d the retval then it could have spotted the bug.
I think there's a misunderstanding here about the role of CTFE. In general, D compilers do not use CTFE unless the result of the execution is needed at compile-time, e.g. the value is used as a template argument or to determine some compile-time construct like the value of an enum. Indeed, assigning the value of a function call or expression to an enum is the standard idiom for forcing CTFE.
Runtime code like the function shown above have nothing to do with CTFE; the error would be only be caught by VRP (value range propagation) if applied across statements. Unfortunately I don't think current D compilers apply VRP across statements.
> Would it be a nightmare to implement CTFE for arrays, slices and strings?
Again, I think there's a misunderstanding here about exactly what CTFE is and does. CTFE is the *execution* of a function at compile-time, in order to produce a *value* that's used by some compile-time construct. CTFE can certainly work with arrays, slices, strings, and so forth -- as values to be manipulated at compile time, but you seem to have a different meaning in mind here, which is outside of the scope of CTFE. CTFE does not manipulate language *constructs*; it works with actual values, and so can only be applied to code that has already been compiled to the point where it's ready to be turned into machine code for runtime execution. The only difference is that execution takes place in a D interpreter embedded inside the compiler rather than directly on the machine at runtime.
Propagating value ranges and so forth, like you describe above, has nothing to do with CTFE; that's the domain of the compiler's semantic analysis of the code.
> Optimisation of basic operations on these types, in respect of concatenation, slicing and many more operations would be extremely welcome. Would there possibly be a chance to catch many bugs at compile-time?
This has nothing to do with CTFE, but semantic analysis, like VRP, data flow analysis, etc.. D compilers do this to some extent, but not a lot. Walter has been resistant to implement full-blown data flow analysis / VRP across statements, because it would significantly slow down compilation. I'm not 100% but I think the LDC optimizer does this to a greater extent, but this happens rather late in the compilation process (after the front-end has already translated D code into LLVM IR) so it wouldn't catch many semantic bugs that require analysis at a higher level of abstraction.
T
--
The early bird gets the worm. Moral: ewww...
|