[Bug rtl-optimization/114452] New: Functions invoked through compile-time table of function pointers not inlined

[Bug rtl-optimization/114452] New: Functions invoked through compile-time table of function pointers not inlined

[chfast at gmail dot com]

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

            Bug ID: 114452
           Summary: Functions invoked through compile-time table of
                    function pointers not inlined
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: chfast at gmail dot com
  Target Milestone: ---

In the following example there is a compile-time table of pointers to simple
functions. When the table is used in a simple unrolled loop with constant trip
count the functions invoked by pointers are not inlined.

using F = int (*)(int) noexcept;

void test(int z[2]) noexcept {
    static constexpr F fs[]{
        [](int x) noexcept { return x; },
        [](int x) noexcept { return x; },
    };

    for (int i = 0; i < 2; ++i) {
        z[i] = fs[i](z[i]);
    }
}

Generated assembly:

test(int*)::{lambda(int)#1}::_FUN(int):
        mov     eax, edi
        ret
test(int*)::{lambda(int)#2}::_FUN(int):
        mov     eax, edi
        ret
test(int*):
        mov     rdx, rdi
        mov     edi, DWORD PTR [rdi]
        call    test(int*)::{lambda(int)#1}::_FUN(int)
        mov     edi, DWORD PTR [rdx+4]
        mov     DWORD PTR [rdx], eax
        call    test(int*)::{lambda(int)#2}::_FUN(int)
        mov     DWORD PTR [rdx+4], eax
        ret


https://godbolt.org/z/fGqPKh81j

[Bug rtl-optimization/114452] Functions invoked through compile-time table of function pointers not inlined

[xry111 at gcc dot gnu.org]

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

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xry111 at gcc dot gnu.org
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #1 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
Dup.

*** This bug has been marked as a duplicate of bug 111573 ***

[Bug rtl-optimization/114452] Functions invoked through compile-time table of function pointers not inlined

[chfast at gmail dot com]

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

--- Comment #2 from Paweł Bylica <chfast at gmail dot com> ---
I don't think this is related to lambdas. The following is also not optimized:


using F = int (*)(int) noexcept;

inline int impl(int x) noexcept { return x; }

void test(int z[2]) noexcept {
    static constexpr F fs[]{
        impl,
        impl,
    };

    for (int i = 0; i < 2; ++i) {
        z[i] = fs[i](z[i]);
    }
}

https://godbolt.org/z/9hPbzo4Px

[Bug rtl-optimization/114452] Functions invoked through compile-time table of function pointers not inlined

[xry111 at gcc dot gnu.org]

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

--- Comment #3 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to Paweł Bylica from comment #2)
> I don't think this is related to lambdas. The following is also not
> optimized:
> 
> 
> using F = int (*)(int) noexcept;
> 
> inline int impl(int x) noexcept { return x; }
> 
> void test(int z[2]) noexcept {
>     static constexpr F fs[]{
>         impl,
>         impl,
>     };
> 
>     for (int i = 0; i < 2; ++i) {
>         z[i] = fs[i](z[i]);
>     }
> }
> 
> https://godbolt.org/z/9hPbzo4Px

The analysis of PR111573 says:

"So we fail to inline since ipa-prop fails to track the constant function
address.  I think this is really common in typical lambda function usage"

"fails to track the constant function address" applies for normal functions
too.

[Bug rtl-optimization/114452] Functions invoked through compile-time table of function pointers not inlined

[jamborm at gcc dot gnu.org]

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

Martin Jambor <jamborm at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|DUPLICATE                   |---
   Last reconfirmed|                            |2024-03-27
     Ever confirmed|0                           |1

--- Comment #4 from Martin Jambor <jamborm at gcc dot gnu.org> ---
This does not look like a duplicate of PR 111573.

Nevertheless, it is not quite obvious what to do here.  Inlining
happens before unrolling and I am not sure we'd consider unrolling in
early optimizations.  And without unrolling, the load from the array
is not easy to fold.

In this testcase all (well, both) functions referenced from the array
are semantically equivalent which is recognized by ICF but making it
be able to pass this information to the inliner would be
non-trivial... and is this the common case worth optimizing for?

[Bug rtl-optimization/114452] Functions invoked through compile-time table of function pointers not inlined

[xry111 at gcc dot gnu.org]

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

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |NEW
           Keywords|                            |missed-optimization

[Bug rtl-optimization/114452] Functions invoked through compile-time table of function pointers not inlined

[chfast at gmail dot com]

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

--- Comment #5 from Paweł Bylica <chfast at gmail dot com> ---
(In reply to Martin Jambor from comment #4)
> In this testcase all (well, both) functions referenced from the array
> are semantically equivalent which is recognized by ICF but making it
> be able to pass this information to the inliner would be
> non-trivial... and is this the common case worth optimizing for?

I reduced the original code to the array of two identical functions.
Originally, there weren't identical. I can update the test case if this make
more sense.

[Bug rtl-optimization/114452] Functions invoked through compile-time table of function pointers not inlined

[jamborm at gcc dot gnu.org]

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

--- Comment #6 from Martin Jambor <jamborm at gcc dot gnu.org> ---
(In reply to Paweł Bylica from comment #5)
> (In reply to Martin Jambor from comment #4)
> > In this testcase all (well, both) functions referenced from the array
> > are semantically equivalent which is recognized by ICF but making it
> > be able to pass this information to the inliner would be
> > non-trivial... and is this the common case worth optimizing for?
> 
> I reduced the original code to the array of two identical functions.
> Originally, there weren't identical. I can update the test case if this make
> more sense.

Probably not.  But how many elements does the array have in the original code? 
Perhaps we could speculatively inline them if there are only few.

[Bug rtl-optimization/114452] Functions invoked through compile-time table of function pointers not inlined

[chfast at gmail dot com]

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

--- Comment #7 from Paweł Bylica <chfast at gmail dot com> ---
(In reply to Martin Jambor from comment #6)
> (In reply to Paweł Bylica from comment #5)
> > (In reply to Martin Jambor from comment #4)
> > > In this testcase all (well, both) functions referenced from the array
> > > are semantically equivalent which is recognized by ICF but making it
> > > be able to pass this information to the inliner would be
> > > non-trivial... and is this the common case worth optimizing for?
> > 
> > I reduced the original code to the array of two identical functions.
> > Originally, there weren't identical. I can update the test case if this make
> > more sense.
> 
> Probably not.  But how many elements does the array have in the original
> code?  Perhaps we could speculatively inline them if there are only few.

5. These are boolean functions from RIPEMD160.