4 ms·

Hey, by all means fix clang and gcc so that my example no longer requires a runtime call to mul(). After all, evaluating code at compile time is easy right? I

by NavinF 5y ago

Hey, by all means fix clang and gcc so that my example no longer requires a runtime call to mul(). After all, evaluating code at compile time is easy right? If you succeed in solving this problem in general, feel free to propose a change to the language that allows the use of expressions such as `mul(arr, arr+len)` anywhere you'd normally be required to use a constant. (That's what constexpr already achieves today) Btw I mentioned that you can make the compiler try harder with LLVM opt because constant-folding is an optimization. I dunno why you bring up codegen.

manwe150 5y ago
Since the compiler must verify the expression is constexpr-valid, it could annotate that automatically instead. However, I believe that generally the standard requires that the keyword be explicit so that compilers agree on what are legal programs, and don’t just declare it to be implementation-defined for what is legal in const-initializer contexts. But in clang, you’d need an frontend-optimization framework to do that reliably (due to recursion), and it doesn’t have one. In llvm, the Attributer framework is still relatively new, but is progressing towards that.
- dataflow 5y ago
  > However, I believe that generally the standard requires that the keyword be explicit so that compilers agree on what are legal programs, and don’t just declare it to be implementation-defined for what is legal in const-initializer contexts. The standard could just declare that anything that could be constexpr-evaluable must be evaluated at compile time up to a depth of at least N, or something like that, after which it is permitted (but not obligated) to be evaluated at runtime. Just like with templates, except over there the implementation just errors out if the template gets too complicated or impossible to evaluate. The standard already has minimum criteria like these for a ton of other cases so this wouldn't be any different to justify a keyword for it.
dataflow 5y ago
> Hey, by all means fix clang and gcc so that my example no longer requires a runtime call to mul(). They can just pretend every inline function has constexpr in front of it, and fall back to compiling them if they fail to evaluate it as constexpr. The constexpr doesn't tell the compiler anything it didn't already know or have to verify anyway. And bear in mind much of the standard library already has constexpr in front of it (and that's a pretty strong signal that it should've been implicit IMO). I don't know Clang or GCC's codebases to know exactly what to modify off the top of my head, but I'm pretty sure adding an extra 'constexpr' internally in the front-end would be utterly trivial as far as compilers go. No need for any optimizations to get involved (and it's important to understand this).

by NavinF 5y ago

manwe150 5y ago

Since the compiler must verify the expression is constexpr-valid, it could annotate that automatically instead. However, I believe that generally the standard requires that the keyword be explicit so that compilers agree on what are legal programs, and don’t just declare it to be implementation-defined for what is legal in const-initializer contexts. But in clang, you’d need an frontend-optimization framework to do that reliably (due to recursion), and it doesn’t have one. In llvm, the Attributer framework is still relatively new, but is progressing towards that.

dataflow 5y ago
> However, I believe that generally the standard requires that the keyword be explicit so that compilers agree on what are legal programs, and don’t just declare it to be implementation-defined for what is legal in const-initializer contexts. The standard could just declare that anything that could be constexpr-evaluable must be evaluated at compile time up to a depth of at least N, or something like that, after which it is permitted (but not obligated) to be evaluated at runtime. Just like with templates, except over there the implementation just errors out if the template gets too complicated or impossible to evaluate. The standard already has minimum criteria like these for a ton of other cases so this wouldn't be any different to justify a keyword for it.

dataflow 5y ago

> Hey, by all means fix clang and gcc so that my example no longer requires a runtime call to mul(). They can just pretend every inline function has constexpr in front of it, and fall back to compiling them if they fail to evaluate it as constexpr. The constexpr doesn't tell the compiler anything it didn't already know or have to verify anyway. And bear in mind much of the standard library already has constexpr in front of it (and that's a pretty strong signal that it should've been implicit IMO). I don't know Clang or GCC's codebases to know exactly what to modify off the top of my head, but I'm pretty sure adding an extra 'constexpr' internally in the front-end would be utterly trivial as far as compilers go. No need for any optimizations to get involved (and it's important to understand this).