[Bug rtl-optimization/114452] Functions invoked through compile-time table of function pointers not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114452 --- Comment #7 from Paweł Bylica --- (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.
[Bug rtl-optimization/114452] Functions invoked through compile-time table of function pointers not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114452 --- Comment #6 from Martin Jambor --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114452 --- Comment #5 from Paweł Bylica --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114452 Xi Ruoyao 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114452 Martin Jambor changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE |--- Last reconfirmed||2024-03-27 Ever confirmed|0 |1 --- Comment #4 from Martin Jambor --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114452
--- Comment #3 from Xi Ruoyao ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114452
--- Comment #2 from Paweł Bylica ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114452 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Xi Ruoyao --- Dup. *** This bug has been marked as a duplicate of bug 111573 ***
