[Bug tree-optimization/95769] New: Constant expression in inline function not optimized

[Bug tree-optimization/95769] New: Constant expression in inline function not optimized

[gcc at mailinator dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95769

            Bug ID: 95769
           Summary: Constant expression in inline function not optimized
           Product: gcc
           Version: 10.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gcc at mailinator dot com
  Target Milestone: ---

Godbolt link: https://godbolt.org/z/Kimna8

Code:

```
int constexpr expensive_function(int x){
    int result{};
    while(x!=1){
        x=x%2!=0 ? x*3+1 : x/2;
        result++;
    }
    return result;
}

int constexpr other_function(int a, int b){
    return a*expensive_function(b);
}

int f_(int x){
    return other_function(x, 1000);
}

int g(int x){
    return x*expensive_function(1000);
}
```

The function `g` is optimized so `expensive_function(1000)` is evaluated at
compile time. The function `f` isn't.

[Bug tree-optimization/95769] Constant expression in inline function not optimized

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95769

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
If you want to ensure a function is evaluated at compile time, it needs to be
either C++20 consteval, or you need to evaluate it in constant expression
context, e.g. constexpr auto x = expensive_function(10000);

[Bug tree-optimization/95769] Constant expression in inline function not optimized

[gcc at mailinator dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95769

--- Comment #2 from John Simon <gcc at mailinator dot com> ---
(In reply to Jakub Jelinek from comment #1)
> If you want to ensure a function is evaluated at compile time, it needs to
> be either C++20 consteval, or you need to evaluate it in constant expression
> context, e.g. constexpr auto x = expensive_function(10000);

in this case, doing that will make the `other_function` consteval too, so I
can't call it with non-constant values.

[Bug tree-optimization/95769] Constant expression in inline function not optimized

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95769

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to John Simon from comment #2)
> (In reply to Jakub Jelinek from comment #1)
> > If you want to ensure a function is evaluated at compile time, it needs to
> > be either C++20 consteval, or you need to evaluate it in constant expression
> > context, e.g. constexpr auto x = expensive_function(10000);
> 
> in this case, doing that will make the `other_function` consteval too, so I
> can't call it with non-constant values.

So you can't make it consteval then, but you can still assign it into const
variable (or even constinit in C++20 to abort compilation if not evaluated into
constant).  Without that, the constexpr means nothing, the compiler might or
might not evaluate it at compile time.

[Bug tree-optimization/95769] Constant expression in inline function not optimized

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95769

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
And, in the compiler the C++ constant evaluation is something done only in the
C++ FE, while you are looking for IPA constant propagation and based on that
performing the C++ FE constant evaluation because that function had constexpr.

[Bug ipa/95769] Constant expression in inline function not optimized

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95769

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
If we are going to optimize this at IPA time, I'll note we'd need a separate
middle-end IL evaluation code, because the FE one isn't usable for this (not
even through a langhook), because it relies on the IL being unfolded FE trees
and has all the language imposed restrictions etc.
I think I've mentioned IL evaluation as something useful for loops to be able
to evaluate all their side-effects and judge if they are small enough (not too
much overwritten memory, etc.) to replace the original loop, and if we have it,
using it for functions to whose arguments we propagate constants, perhaps using
the constexpr as a hint to try somewhat longer, could work.