public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug analyzer/107060] New: -fanalyzer unbearably slow when compiling GNU Emacs
@ 2022-09-27 19:20 eggert at cs dot ucla.edu
  2022-09-27 20:55 ` [Bug analyzer/107060] " dmalcolm at gcc dot gnu.org
                   ` (8 more replies)
  0 siblings, 9 replies; 10+ messages in thread
From: eggert at cs dot ucla.edu @ 2022-09-27 19:20 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 107060
           Summary: -fanalyzer unbearably slow when compiling GNU Emacs
           Product: gcc
           Version: 12.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: analyzer
          Assignee: dmalcolm at gcc dot gnu.org
          Reporter: eggert at cs dot ucla.edu
  Target Milestone: ---

Created attachment 53634
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53634&action=edit
compressed source file that gcc -S -fanalyzer -O2 compiles verrrry slowly

For a while, gcc -fanalyzer has been so unbearably slow when compiling GNU
Emacs that we Emacs developers disable -fanalyzer unless the builder
specifically asks for it, which almost nobody does because it's sooo slow. I
haven't bothered to file a bug report because I assumed the analyzer code was
still being worked on and tuned, but I just now tried -fanalyzer again on a new
machine and it was still so slow that I am finally filing a bug report.

The biggest pole in the tent is when gcc compiles Emacs's xdisp.c file, which
is large for Emacs (38 Klines) but not that large. I am attaching the
preprocessed output as the file u.i.gz. Compile it with:

gzip -d u.i
gcc -S -fanalyzer -O2 u.i

On my older Fedora 36 desktop (AMD Phenom II X4 910e) with gcc (GCC) 12.2.1
20220819 (Red Hat 12.2.1-2) GCC takes 12 minutes 3 seconds, which is
ridiculous. On my newer Ubuntu 22.04 desktop (Intel Xeon W-1350) with gcc-12
(Ubuntu 12.1.0-2ubuntu1~22.04) 12.1.0, GCC takes 3 minutes 43 seconds, which is
still way too long.

Could you please take a look at this test case and see what's slowing down
-fanalyzer? If you can't improve GCC, is there some easy way we Emacs
developers can rewrite the source to avoid the performance issue, whatever it
is? Thanks.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug analyzer/107060] -fanalyzer unbearably slow when compiling GNU Emacs
  2022-09-27 19:20 [Bug analyzer/107060] New: -fanalyzer unbearably slow when compiling GNU Emacs eggert at cs dot ucla.edu
@ 2022-09-27 20:55 ` dmalcolm at gcc dot gnu.org
  2022-09-27 21:31 ` dmalcolm at gcc dot gnu.org
                   ` (7 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: dmalcolm at gcc dot gnu.org @ 2022-09-27 20:55 UTC (permalink / raw)
  To: gcc-bugs

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

David Malcolm <dmalcolm at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2022-09-27

--- Comment #1 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Thanks for filing this bug; I'm taking a look.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug analyzer/107060] -fanalyzer unbearably slow when compiling GNU Emacs
  2022-09-27 19:20 [Bug analyzer/107060] New: -fanalyzer unbearably slow when compiling GNU Emacs eggert at cs dot ucla.edu
  2022-09-27 20:55 ` [Bug analyzer/107060] " dmalcolm at gcc dot gnu.org
@ 2022-09-27 21:31 ` dmalcolm at gcc dot gnu.org
  2022-09-27 22:22 ` dmalcolm at gcc dot gnu.org
                   ` (6 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: dmalcolm at gcc dot gnu.org @ 2022-09-27 21:31 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #2 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Confirmed: the test case on a release build of trunk on my development box:
  -O2 without -fanalyzer takes ~18 seconds
  -O2 with -fanalyzer takes ~10 minutes == ~600 seconds

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug analyzer/107060] -fanalyzer unbearably slow when compiling GNU Emacs
  2022-09-27 19:20 [Bug analyzer/107060] New: -fanalyzer unbearably slow when compiling GNU Emacs eggert at cs dot ucla.edu
  2022-09-27 20:55 ` [Bug analyzer/107060] " dmalcolm at gcc dot gnu.org
  2022-09-27 21:31 ` dmalcolm at gcc dot gnu.org
@ 2022-09-27 22:22 ` dmalcolm at gcc dot gnu.org
  2022-09-28 13:57 ` dmalcolm at gcc dot gnu.org
                   ` (5 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: dmalcolm at gcc dot gnu.org @ 2022-09-27 22:22 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #3 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
perf shows that 64% of the time is taken by this ctor:
  shortest_paths<ana::eg_traits, ana::exploded_path>::shortest_paths

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug analyzer/107060] -fanalyzer unbearably slow when compiling GNU Emacs
  2022-09-27 19:20 [Bug analyzer/107060] New: -fanalyzer unbearably slow when compiling GNU Emacs eggert at cs dot ucla.edu
                   ` (2 preceding siblings ...)
  2022-09-27 22:22 ` dmalcolm at gcc dot gnu.org
@ 2022-09-28 13:57 ` dmalcolm at gcc dot gnu.org
  2022-09-28 15:01 ` dmalcolm at gcc dot gnu.org
                   ` (4 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: dmalcolm at gcc dot gnu.org @ 2022-09-28 13:57 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #4 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
(In reply to David Malcolm from comment #3)
> perf shows that 64% of the time is taken by this ctor:
>   shortest_paths<ana::eg_traits, ana::exploded_path>::shortest_paths

This is in the "find shortest feasible path for a diagnostic" code.

FWIW, adding -fno-analyzer-feasibility reduces the time for me from 10 minutes
to about 4.5 minutes (better, but still far too slow), and makes it emit a
false positive.

I'm investigating where the slowdowns are.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug analyzer/107060] -fanalyzer unbearably slow when compiling GNU Emacs
  2022-09-27 19:20 [Bug analyzer/107060] New: -fanalyzer unbearably slow when compiling GNU Emacs eggert at cs dot ucla.edu
                   ` (3 preceding siblings ...)
  2022-09-28 13:57 ` dmalcolm at gcc dot gnu.org
@ 2022-09-28 15:01 ` dmalcolm at gcc dot gnu.org
  2022-09-29  8:10 ` rguenth at gcc dot gnu.org
                   ` (3 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: dmalcolm at gcc dot gnu.org @ 2022-09-28 15:01 UTC (permalink / raw)
  To: gcc-bugs

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

David Malcolm <dmalcolm at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|                            |99390

--- Comment #5 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
The real issue here is that -fanalyzer-call-summaries is off by default (due to
being buggy).  Poring over the dumps shows that without trying to summarize the
effects of calls, the analyzer is brute-forcing the exploration of the call
graph, leading to an explosion of deep paths, expensively achieving very poor
coverage.

Enabling -fanalyzer-call-summaries speeds things up from ~10 minutes to ~1m20s
(7.5x), but makes it emit lots of -Wanalyzer-use-of-uninitialized-value false
positives.  Am about to file a bug about that...

Sorry about this; I'd recommend disabling -fanalyzer on Emacs until it's
reasonable to enable -fanalyzer-call-summaries on it.

The dumps show some other issues, like the analyzer seems to be creating lots
of regions for tracking "alloca" (~45000 of them in one dump), so I may need to
also fix how alloca is handled.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99390
[Bug 99390] [meta-bug] tracker bug for call summaries in -fanalyzer

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug analyzer/107060] -fanalyzer unbearably slow when compiling GNU Emacs
  2022-09-27 19:20 [Bug analyzer/107060] New: -fanalyzer unbearably slow when compiling GNU Emacs eggert at cs dot ucla.edu
                   ` (4 preceding siblings ...)
  2022-09-28 15:01 ` dmalcolm at gcc dot gnu.org
@ 2022-09-29  8:10 ` rguenth at gcc dot gnu.org
  2022-10-05 17:54 ` cvs-commit at gcc dot gnu.org
                   ` (2 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-09-29  8:10 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
One approach (usually taken by GCC ...) is to add --param tunables and
hard-limit search depth/width and number-of-FOO to track with providing means
to
up those limits.  Both to limit compile-time but also memory-usage.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug analyzer/107060] -fanalyzer unbearably slow when compiling GNU Emacs
  2022-09-27 19:20 [Bug analyzer/107060] New: -fanalyzer unbearably slow when compiling GNU Emacs eggert at cs dot ucla.edu
                   ` (5 preceding siblings ...)
  2022-09-29  8:10 ` rguenth at gcc dot gnu.org
@ 2022-10-05 17:54 ` cvs-commit at gcc dot gnu.org
  2022-10-05 18:20 ` dmalcolm at gcc dot gnu.org
  2023-03-02 18:26 ` dmalcolm at gcc dot gnu.org
  8 siblings, 0 replies; 10+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-10-05 17:54 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by David Malcolm <dmalcolm@gcc.gnu.org>:

https://gcc.gnu.org/g:6832c95c0e1a58ba4d342ec002000f9d9d7db5ca

commit r13-3094-g6832c95c0e1a58ba4d342ec002000f9d9d7db5ca
Author: David Malcolm <dmalcolm@redhat.com>
Date:   Wed Oct 5 13:52:59 2022 -0400

    analyzer: fix ICEs seen with call summaries on PR 107060

    This doesn't fix the various false positives seen with
    -fanalyzer-call-summaries on PR 107060, but stops it crashing at -O2.

    gcc/analyzer/ChangeLog:
            PR analyzer/107060
            * call-summary.cc
            (call_summary_replay::convert_svalue_from_summary_1): Handle NULL
            results from convert_svalue_from_summary in SK_UNARY_OP and
            SK_BIN_OP.
            * engine.cc (impl_region_model_context::on_unknown_change): Bail
            out on svalues that can't have associated state.
            * region-model-impl-calls.cc
            (region_model::impl_call_analyzer_get_unknown_ptr): New.
            * region-model.cc (region_model::on_stmt_pre): Handle
            "__analyzer_get_unknown_ptr".
            * region-model.h
            (region_model::impl_call_analyzer_get_unknown_ptr): New decl.
            * store.cc (store::replay_call_summary_cluster): Avoid trying to
            create binding clusters for base regions that shouldn't have them.

    gcc/ChangeLog:
            PR analyzer/107060
            * doc/analyzer.texi (__analyzer_get_unknown_ptr): Document.

    gcc/testsuite/ChangeLog:
            PR analyzer/107060
            * gcc.dg/analyzer/analyzer-decls.h (__analyzer_get_unknown_ptr):
            New decl.
            * gcc.dg/analyzer/call-summaries-2.c
            (test_summarized_writes_param_to_ptr_unknown): New test.

    Signed-off-by: David Malcolm <dmalcolm@redhat.com>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug analyzer/107060] -fanalyzer unbearably slow when compiling GNU Emacs
  2022-09-27 19:20 [Bug analyzer/107060] New: -fanalyzer unbearably slow when compiling GNU Emacs eggert at cs dot ucla.edu
                   ` (6 preceding siblings ...)
  2022-10-05 17:54 ` cvs-commit at gcc dot gnu.org
@ 2022-10-05 18:20 ` dmalcolm at gcc dot gnu.org
  2023-03-02 18:26 ` dmalcolm at gcc dot gnu.org
  8 siblings, 0 replies; 10+ messages in thread
From: dmalcolm at gcc dot gnu.org @ 2022-10-05 18:20 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #8 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
The patch for PR analyzer/107072 and the above patch mean that we get more
reasonable summaries when using -fanalyzer-call-summaries.  Unfortunately:
- it actually slows down the analysis for PR 107060 on my box, from 10 minutes
to 22 minutes at -O2, and
- leads to lots of diagnostics.  Given e.g. the false positives seen in PR
analyzer/107158, I don't trust these diagnostics.

Hence I don't recommend turning on -fanalyzer-call-summaries yet.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug analyzer/107060] -fanalyzer unbearably slow when compiling GNU Emacs
  2022-09-27 19:20 [Bug analyzer/107060] New: -fanalyzer unbearably slow when compiling GNU Emacs eggert at cs dot ucla.edu
                   ` (7 preceding siblings ...)
  2022-10-05 18:20 ` dmalcolm at gcc dot gnu.org
@ 2023-03-02 18:26 ` dmalcolm at gcc dot gnu.org
  8 siblings, 0 replies; 10+ messages in thread
From: dmalcolm at gcc dot gnu.org @ 2023-03-02 18:26 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #9 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Reconfirming, alas.  I just tried adding emacs to my integration test suite
[1], and xdisp.c is still a big outlier, taking ~15 minutes; with gcc (GCC)
13.0.1 20230202 (experimental).

[1] https://github.com/davidmalcolm/gcc-analyzer-integration-tests/issues/2

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2023-03-02 18:26 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-27 19:20 [Bug analyzer/107060] New: -fanalyzer unbearably slow when compiling GNU Emacs eggert at cs dot ucla.edu
2022-09-27 20:55 ` [Bug analyzer/107060] " dmalcolm at gcc dot gnu.org
2022-09-27 21:31 ` dmalcolm at gcc dot gnu.org
2022-09-27 22:22 ` dmalcolm at gcc dot gnu.org
2022-09-28 13:57 ` dmalcolm at gcc dot gnu.org
2022-09-28 15:01 ` dmalcolm at gcc dot gnu.org
2022-09-29  8:10 ` rguenth at gcc dot gnu.org
2022-10-05 17:54 ` cvs-commit at gcc dot gnu.org
2022-10-05 18:20 ` dmalcolm at gcc dot gnu.org
2023-03-02 18:26 ` dmalcolm at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).