Created attachment 25014 [details] runs_too_long runs in a very short period of time I have two nearly identical programs. In one (small.joe.cpp), a function called 'runs_too_long' does not run too long. It is compiled down to returning a constant value. In another, very slightly different program (small-nojoe.cpp), the function 'runs_too_long' does indeed run too long. It, in fact will not complete in any reasonable length of time.
Created attachment 25015 [details] The function 'runs_too_long' takes basically forever
I can't reproduce this. Maybe Jason wants to double check.
This is more or less expected behavior. Since a const variable declaration has different semantics depending on whether or not the initializer is a constant-expression, a compiler needs to find a constant value if there is one. So we do, and joe is initialized with that constant value. But in the second testcase, there is no semantic constraint on whether or not the call fib(92) is a constant-expression, so we don't try to reduce it to a constant, assuming that normal optimization can do just as well. But for whatever reason, in this case normal optimization isn't doing as well as constexpr evaluation can.
(for the record: I somehow wrongly understood long, "forever" *compile*-time)
I thought that perhaps it was expected behavior. I still think it's a missed optimization opportunity. A call of a constexpr function can clearly, in all cases, be reduced to a constant expression if the arguments are also constant expressions. So it seems like the optimizer should do this if it can. But it isn't a 'bug' exactly, just more of a 'it could do this better'.
(In reply to comment #5) > I still think it's a missed optimization opportunity. Yes, it definitely is. I'm just not sure whether it should be fixed by doing constexpr expansion in non-constant expression contexts in some cases, or improving normal optimization to handle this case.
(In reply to comment #6) > (In reply to comment #5) > > I still think it's a missed optimization opportunity. > > Yes, it definitely is. I'm just not sure whether it should be fixed by doing > constexpr expansion in non-constant expression contexts in some cases, or > improving normal optimization to handle this case. That's an interesting question. I think improving normal optimization to handle this case might prove to be rather tricky. It would basically require detecting that a function could be constexpr even if it wasn't declared that way. Otherwise, a deep recursion case like this is really a pain to deal with at optimization time. I can think of cases where I have created templates for finding GCDs (using Euclid's algorithm), integer logarithms and integer exponents at compile time that are not toy problems. GCDs in particular are at least is tricky as the silly bad recursive Fibonacci number generator. Of course, I'm only guessing. Compilers and optimizers are not my thing. It just seems like using the constexpr logic in some cases would be a lot easier.