[Bug middle-end/112312] New: GCC fails to optimize a C++ algorithm with a function passed in as well as with a lambda

[Bug middle-end/112312] New: GCC fails to optimize a C++ algorithm with a function passed in as well as with a lambda

[ville.voutilainen at gmail dot com]

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

            Bug ID: 112312
           Summary: GCC fails to optimize a C++ algorithm with a function
                    passed in as well as with a lambda
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ville.voutilainen at gmail dot com
  Target Milestone: ---

See 
https://godbolt.org/z/s8dWGzb9r

When passing a (pointer to) function as a predicate argument for a C++ stdlib
algorithm, various people hope that it optimizes as well as passing a lambda
that does exactly the same thing. And with clang, it does. With gcc, the
generated
code is much worse for the function case, even though the function definition
is nearby and visible.

The test code used on godbolt pasted for convenience:

#include <string>
#include <vector>
#include <algorithm>

static bool pred1(const std::string& a, const std::string& b)
{
    return false;
}

auto pred2 = [](const std::string& a, const std::string& b)
{
    return false;
};

bool func1(const std::vector<std::string>& vec, const std::string& needle)
{
    return std::ranges::lower_bound(vec, needle, pred1) != vec.end();
}

bool func2(const std::vector<std::string>& vec, const std::string& needle)
{
    return std::ranges::lower_bound(vec, needle, pred2) != vec.end();
}

[Bug middle-end/112312] GCC fails to optimize a C++ algorithm with a function passed in as well as with a lambda

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
-O2 produces good code while -O3 does not ...

[Bug tree-optimization/112312] GCC fails to optimize a C++ algorithm with a function passed in as well as with a lambda

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|middle-end                  |tree-optimization

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The difference is when inlining happens of specific functions.
at -O3, more functions are inlined during the early inlining phase while they
happen at -O2 during later on.

[Bug tree-optimization/112312] -O3 produces worse code than -O2 for std::ranges::lower_bound in some cases, not marking a loop as finite

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-10-31
     Ever confirmed|0                           |1
            Summary|-O3 produces worse code     |-O3 produces worse code
                   |than -O2 for                |than -O2 for
                   |std::ranges::lower_bound in |std::ranges::lower_bound in
                   |some cases, not removing an |some cases, not marking a
                   |empty loop                  |loop as finite
             Status|UNCONFIRMED                 |NEW

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed.

So further difference is the loop seems not to be marked as finite while with
-O2 (or the non-lamdba version) is.

Someone will need to figure out if and where we lose the idea of the finite
loopness.

[Bug tree-optimization/112312] -O3 produces worse code than -O2 for std::ranges::lower_bound in some cases, not marking a loop as finite

[jamborm at gcc dot gnu.org]

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

--- Comment #4 from Martin Jambor <jamborm at gcc dot gnu.org> ---
It seems this has been fixed in current master (which is to become gcc 14).
If my bisecting is correct, it has been fixed by r14-5628-g53ba8d669550d3 (Jan
Hubicka: inter-procedural value range propagation).

I guess it would be nice to add this testcase to the testsuite, so I'm keeping
this bug opened (and on my TODO list).