public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug middle-end/28614] gcc.c-torture/compile/20001226-1.c times out
       [not found] <bug-28614-4@http.gcc.gnu.org/bugzilla/>
@ 2023-02-06 12:31 ` rguenth at gcc dot gnu.org
  2023-02-13 14:57 ` cvs-commit at gcc dot gnu.org
  1 sibling, 0 replies; 2+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-02-06 12:31 UTC (permalink / raw)
  To: gcc-bugs

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
FRE seems to take most of the time on this testcase.

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

* [Bug middle-end/28614] gcc.c-torture/compile/20001226-1.c times out
       [not found] <bug-28614-4@http.gcc.gnu.org/bugzilla/>
  2023-02-06 12:31 ` [Bug middle-end/28614] gcc.c-torture/compile/20001226-1.c times out rguenth at gcc dot gnu.org
@ 2023-02-13 14:57 ` cvs-commit at gcc dot gnu.org
  1 sibling, 0 replies; 2+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-02-13 14:57 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:72ae1e5635648bd3f6a5760ca46d531ad1f2c6b1

commit r13-5966-g72ae1e5635648bd3f6a5760ca46d531ad1f2c6b1
Author: Richard Biener <rguenther@suse.de>
Date:   Mon Feb 13 14:41:24 2023 +0100

    tree-optimization/28614 - high FRE time for
gcc.c-torture/compile/20001226-1.c

    I noticed that for gcc.c-torture/compile/20001226-1.c even -O1 has
    around 50% of the compile-time accounted to FRE.  That's because
    we have blocks with a high incoming edge count and
    can_track_predicate_on_edge visits all of them even though it could
    stop after the second.  The function is also called repeatedly for
    the same edge.  The following fixes this and reduces the FRE time
    to 1% on the testcase.

            PR tree-optimization/28614
            * tree-ssa-sccvn.cc (can_track_predicate_on_edge): Avoid
            walking all edges in most cases.
            (vn_nary_op_insert_pieces_predicated): Avoid repeated
            calls to can_track_predicate_on_edge unless checking is
            enabled.
            (process_bb): Instead call it once here for each edge
            we register possibly multiple predicates on.

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

end of thread, other threads:[~2023-02-13 14:57 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <bug-28614-4@http.gcc.gnu.org/bugzilla/>
2023-02-06 12:31 ` [Bug middle-end/28614] gcc.c-torture/compile/20001226-1.c times out rguenth at gcc dot gnu.org
2023-02-13 14:57 ` cvs-commit 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).