Bug 94818 - GCC emits dead bodies of functions whose all calls have been eliminated by optimisations
Summary: GCC emits dead bodies of functions whose all calls have been eliminated by op...
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: ipa (show other bugs)
Version: 10.0
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: missed-optimization
Depends on: 47205 89139
Blocks: 92497 101941 102361
  Show dependency treegraph
 
Reported: 2020-04-28 12:43 UTC by felix
Modified: 2022-08-09 16:24 UTC (History)
1 user (show)

See Also:
Host:
Target: x86_64-linux-gnu
Build:
Known to work:
Known to fail:
Last reconfirmed: 2020-04-28 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description felix 2020-04-28 12:43:51 UTC
In this code:

    __attribute__((__warning__("argh")))
    static void foo(void) {
        __asm__ (
            ";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;"
            ";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;"
        );
    }

    void bar0(int x) {
        if (__builtin_constant_p(x))
            foo();
    }

    void bar1(int x) {
        if (__builtin_constant_p(x))
            foo();
    }

No calls to foo are emitted in the final output, and GCC knows this, since no warnings are emitted. However, GCC will still emit a function body for foo, unless either the __asm__ statement is removed or both conditions are changed to integer constant expressions, so that the function is eliminated by one of the inlining passes.

(I decided to demonstrate it this way instead of using __attribute__((__noinline__)), just to make sure this is not related to __attribute__((__noinline__)) somehow implying __attribute__((__used__)).)
Comment 1 Richard Biener 2020-04-28 13:36:15 UTC
Confirmed.  ___builtin_constant_p is only resolved after IPA optimization and
at that point unreachable functions can no longer be removed reliably
(foo is output before bar0 __builtin_constant_p is resolved).

We could add another "IPA" sync point before RTL expansion but not sure if
we really want to.

We could also see there's no callers to bar0 and bar1 and resolve
__builtin_constant_p earlier during IPA.
Comment 2 Andrew Pinski 2020-04-29 06:27:04 UTC
Related to PR 47205, PR 89139