[Bug c++/50087] New: Weird optimization anomoly with constexpr

[Bug c++/50087] New: Weird optimization anomoly with constexpr

[eric-gcc at omnifarious dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50087

             Bug #: 50087
           Summary: Weird optimization anomoly with constexpr
    Classification: Unclassified
           Product: gcc
           Version: 4.6.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: eric-gcc@omnifarious.org


Created attachment 25014
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25014
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.

[Bug c++/50087] Weird optimization anomoly with constexpr

[eric-gcc at omnifarious dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50087

--- Comment #1 from eric-gcc at omnifarious dot org 2011-08-15 12:49:16 UTC ---
Created attachment 25015
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25015
The function 'runs_too_long' takes basically forever

[Bug c++/50087] [C++0x] Weird optimization anomaly with constexpr

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50087

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu.org

--- Comment #2 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-08-15 13:36:33 UTC ---
I can't reproduce this. Maybe Jason wants to double check.

[Bug c++/50087] [C++0x] Weird optimization anomaly with constexpr

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50087

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011-08-16
     Ever Confirmed|0                           |1

--- Comment #3 from Jason Merrill <jason at gcc dot gnu.org> 2011-08-16 21:38:01 UTC ---
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.

[Bug c++/50087] [C++0x] Weird optimization anomaly with constexpr

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50087

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |paolo.carlini at oracle dot
                   |                            |com

--- Comment #4 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-08-16 21:48:59 UTC ---
(for the record: I somehow wrongly understood long, "forever" *compile*-time)

[Bug c++/50087] [C++0x] Weird optimization anomaly with constexpr

[eric-bugs at omnifarious dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50087

eric-bugs at omnifarious dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |eric-bugs at omnifarious
                   |                            |dot org

--- Comment #5 from eric-bugs at omnifarious dot org 2011-09-02 20:57:45 UTC ---
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'.

[Bug c++/50087] [C++0x] Weird optimization anomaly with constexpr

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50087

--- Comment #6 from Jason Merrill <jason at gcc dot gnu.org> 2011-09-03 00:48:25 UTC ---
(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.

[Bug c++/50087] [C++0x] Weird optimization anomaly with constexpr

[eric-gcc at omnifarious dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50087

--- Comment #7 from eric-gcc at omnifarious dot org 2011-09-13 22:15:16 UTC ---
(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.