Too aggresive C++23 static call operator optimization

[shtanko-sv]

Hello,

It looks like clang is too aggressive for C++23 static call optimization. Here is the simplified example of real code:

#include <functional>
#include <iostream>

template <typename Tag>
struct Wrapper {
    template <typename F, typename... Args>
    static void operator()(F&& callable, Args&&... args) {
        Invoke(std::forward<F>(callable), std::forward<Args>(args)...);
    }

    template <typename F, typename... Args>
    static void Invoke(F&& callable, Args&&... args) {
        std::invoke(std::forward<F>(callable), std::forward<Args>(args)...);
    }
};

struct Manager {
    template <typename SingletonClass>
    static SingletonClass& Get() {
        std::cout << "get call\n";
        static SingletonClass instance;
        return instance;
    }
};

struct Tag {};

int main()
{
    using TaggedWrapper = Wrapper<Tag>;
    Manager::Get<TaggedWrapper>()([] { std::cout << "Function\n"; });
}

We assume that Manager::Get() will be called and get call will be printed, but it doesn't happen. If change call in main to Manager::Get<TaggedWrapper>().Invoke([] { std::cout << "Function\n"; }); it works as expected. get cal also will be printed if remove static from operator(). It reproducible even with -O0. clang-17.0.1

[dtcxzyw]

Godbolt: https://godbolt.org/z/d8sG1so1h
It seems like clang didn't emit llvm ir for the statement std::cout << "get call\n";.

[llvmbot]

@llvm/issue-subscribers-bug

Hello,

It looks like clang is too aggressive for C++23 static call optimization. Here is the simplified example of real code:

#include <functional>
#include <iostream>

template <typename Tag>
struct Wrapper {
    template <typename F, typename... Args>
    static void operator()(F&& callable, Args&&... args) {
        Invoke(std::forward<F>(callable), std::forward<Args>(args)...);
    }

    template <typename F, typename... Args>
    static void Invoke(F&& callable, Args&&... args) {
        std::invoke(std::forward<F>(callable), std::forward<Args>(args)...);
    }
};

struct Manager {
    template <typename SingletonClass>
    static SingletonClass& Get() {
        std::cout << "get call\n";
        static SingletonClass instance;
        return instance;
    }
};

struct Tag {};

int main()
{
    using TaggedWrapper = Wrapper<Tag>;
    Manager::Get<TaggedWrapper>()([] { std::cout << "Function\n"; });
}

We assume that Manager::Get() will be called and get call will be printed, but it doesn't happen. If change call in main to Manager::Get<TaggedWrapper>().Invoke([] { std::cout << "Function\n"; }); it works as expected. get cal also will be printed if remove static from operator(). It reproducible even with -O0. clang-17.0.1

[dtcxzyw]

Reduced code: https://godbolt.org/z/q84zajYGs

#include <iostream>

struct Wrapper {
    static void operator()() {
        std::cout << "Function\n";
    }
};

static Wrapper instance;
struct Manager {
    static Wrapper& Get() {
        std::cout << "get call\n";
        return instance;
    }
};

int main() {
    Manager::Get()();
    return 0;
}

The expression Manager::Get() is not evaluated.
Related patch: https://reviews.llvm.org/D133659

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Hello,

It looks like clang is too aggressive for C++23 static call optimization. Here is the simplified example of real code:

#include <functional>
#include <iostream>

template <typename Tag>
struct Wrapper {
    template <typename F, typename... Args>
    static void operator()(F&& callable, Args&&... args) {
        Invoke(std::forward<F>(callable), std::forward<Args>(args)...);
    }

    template <typename F, typename... Args>
    static void Invoke(F&& callable, Args&&... args) {
        std::invoke(std::forward<F>(callable), std::forward<Args>(args)...);
    }
};

struct Manager {
    template <typename SingletonClass>
    static SingletonClass& Get() {
        std::cout << "get call\n";
        static SingletonClass instance;
        return instance;
    }
};

struct Tag {};

int main()
{
    using TaggedWrapper = Wrapper<Tag>;
    Manager::Get<TaggedWrapper>()([] { std::cout << "Function\n"; });
}

We assume that Manager::Get() will be called and get call will be printed, but it doesn't happen. If change call in main to Manager::Get<TaggedWrapper>().Invoke([] { std::cout << "Function\n"; }); it works as expected. get cal also will be printed if remove static from operator(). It reproducible even with -O0. clang-17.0.1

[llvmbot]

@llvm/issue-subscribers-clang-codegen

Hello,

It looks like clang is too aggressive for C++23 static call optimization. Here is the simplified example of real code:

#include <functional>
#include <iostream>

template <typename Tag>
struct Wrapper {
    template <typename F, typename... Args>
    static void operator()(F&& callable, Args&&... args) {
        Invoke(std::forward<F>(callable), std::forward<Args>(args)...);
    }

    template <typename F, typename... Args>
    static void Invoke(F&& callable, Args&&... args) {
        std::invoke(std::forward<F>(callable), std::forward<Args>(args)...);
    }
};

struct Manager {
    template <typename SingletonClass>
    static SingletonClass& Get() {
        std::cout << "get call\n";
        static SingletonClass instance;
        return instance;
    }
};

struct Tag {};

int main()
{
    using TaggedWrapper = Wrapper<Tag>;
    Manager::Get<TaggedWrapper>()([] { std::cout << "Function\n"; });
}

We assume that Manager::Get() will be called and get call will be printed, but it doesn't happen. If change call in main to Manager::Get<TaggedWrapper>().Invoke([] { std::cout << "Function\n"; }); it works as expected. get cal also will be printed if remove static from operator(). It reproducible even with -O0. clang-17.0.1

[shafik]

If we look at the AST: https://godbolt.org/z/7xExo9oob

`-FunctionDecl <line:17:1, line:20:1> line:17:5 main 'int ()'
  `-CompoundStmt <col:12, line:20:1>
    |-CallExpr <line:18:19, col:20> 'void'
    | `-ImplicitCastExpr <col:19, col:20> 'void (*)()' <FunctionToPointerDecay>
    |   `-DeclRefExpr <col:19, col:20> 'void ()' lvalue CXXMethod 0xf6ea300 'operator()' 'void ()'

It is already elided away. CC @zygoloid

[zygoloid]

Yeah, that AST is clearly wrong. The callee of the outer call expression should be a member access, like it is for a call to operator() by name:

`-FunctionDecl <line:17:1, line:20:1> line:17:5 main 'int ()'
  `-CompoundStmt <col:12, line:20:1>
    |-CallExpr <line:18:5, col:31> 'void'
    | `-ImplicitCastExpr <col:5, col:29> 'void (*)()' <FunctionToPointerDecay>
    |   `-MemberExpr <col:5, col:29> 'void ()' lvalue .operator() 0xf744560
    |     `-CallExpr <col:5, col:18> 'Wrapper':'Wrapper' lvalue
    |       `-ImplicitCastExpr <col:5, col:14> 'Wrapper &(*)()' <FunctionToPointerDecay>
    |         `-DeclRefExpr <col:5, col:14> 'Wrapper &()' lvalue CXXMethod 0xf746478 'Get' 'Wrapper &()'
    |           `-NestedNameSpecifier TypeSpec 'Manager'

The outer call expression should be a CXXOperatorCallExpr, to represent the fact that we're implementing operator syntax via a call to operator$ (in this case, $ = ()).

[SuperSodaSea]

Compare the AST of (static) member/operator calls (https://godbolt.org/z/rn3s49GEz):

struct Foo {
    void f() {}
    void operator()() {}
};
struct Bar {
    static void f() {}
    static void operator()() {}
};

template <typename T>
T& g() {
    static T t;
    return t;
}

g<Foo>().f(); // Non-static member call
/*
CXXMemberCallExpr <line:17:5, col:16> 'void'
`-MemberExpr <col:5, col:14> '<bound member function type>' .f 0xbae3a90
 `-CallExpr <col:5, col:12> 'Foo':'Foo' lvalue
  `-ImplicitCastExpr <col:5, col:10> 'Foo &(*)()' <FunctionToPointerDecay>
   `-DeclRefExpr <col:5, col:10> 'Foo &()' lvalue Function 0xbb03710 'g' 'Foo &()' (FunctionTemplate 0xbae42f0 'g')
*/

g<Foo>()(); // Non-static operator call
/*
CXXOperatorCallExpr <line:18:5, col:14> 'void' '()'
|-ImplicitCastExpr <col:13, col:14> 'void (*)()' <FunctionToPointerDecay>
| `-DeclRefExpr <col:13, col:14> 'void ()' lvalue CXXMethod 0xbae3b78 'operator()' 'void ()'
`-CallExpr <col:5, col:12> 'Foo':'Foo' lvalue
  `-ImplicitCastExpr <col:5, col:10> 'Foo &(*)()' <FunctionToPointerDecay>
    `-DeclRefExpr <col:5, col:10> 'Foo &()' lvalue Function 0xbb03710 'g' 'Foo &()' (FunctionTemplate 0xbae42f0 'g')
*/

g<Bar>().f(); // Static member call (with object)
/*
CallExpr <line:19:5, col:16> 'void'
`-ImplicitCastExpr <col:5, col:14> 'void (*)()' <FunctionToPointerDecay>
  `-MemberExpr <col:5, col:14> 'void ()' lvalue .f 0xbae3eb0
    `-CallExpr <col:5, col:12> 'Bar':'Bar' lvalue
      `-ImplicitCastExpr <col:5, col:10> 'Bar &(*)()' <FunctionToPointerDecay>
        `-DeclRefExpr <col:5, col:10> 'Bar &()' lvalue Function 0xbb03f80 'g' 'Bar &()' (FunctionTemplate 0xbae42f0 'g')
*/

g<Bar>()(); // Static operator call
/*
CallExpr <line:20:13, col:14> 'void'
`-ImplicitCastExpr <col:13, col:14> 'void (*)()' <FunctionToPointerDecay>
  `-DeclRefExpr <col:13, col:14> 'void ()' lvalue CXXMethod 0xbae3f98 'operator()' 'void ()'
*/

If we use CXXOperatorCallExpr for static operator calls, should we use CXXMemberCallExpr for static member calls (with object) for consistency? (Although the current AST for static member calls can produce the correct code)

[zygoloid]

If we use CXXOperatorCallExpr for static operator calls, should we use CXXMemberCallExpr for static member calls (with object) for consistency? (Although the current AST for static member calls can produce the correct code)

Hm, good question, but I don't think so. The only real purpose of CXXMemberCallExpr, as distinguished from CallExpr, is to provide supporting functionality for handling an object parameter. I think it's fine to model these two the same:

struct A {
  static void f();
  void (&g)();
} a;
// A `CallExpr` whose callee is a `MemberExpr`.
a.f();
// A `CallExpr` whose callee is a `MemberExpr`.
a.g();

In contrast, we use CXXOperatorCallExpr for every other case where an operator $ (including function call) is rewritten to a call to a operator$ function, so it would be a departure to use anything else here. Also, CXXOperatorCallExpr already handles both calls to non-static member functions and to non-member functions, so code dealing with it is already in a good place to handle calls to static member functions (which ought to behave like non-member functions in most ways).

[SuperSodaSea]

@dtcxzyw asked me if I'd like to work on this issue, so I'm trying to write a patch for it now. Will create a PR in a few days.

[SuperSodaSea]

PR made: #68485

[SuperSodaSea]

https://godbolt.org/z/qeoEeaWxh
Fix confirmed on trunk! 🎉

Trying to catch up with the 18.x release now -> #80109