public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/102814] [12 regression] quadratique/exponential time complexity for max-jump-thread-duplication-stmts
Date: Wed, 20 Oct 2021 09:09:25 +0000	[thread overview]
Message-ID: <bug-102814-4-YslJG1QkD0@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-102814-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Aldy Hernandez <aldyh@gcc.gnu.org>:

https://gcc.gnu.org/g:82cd78f2c31db1664ca154d7fcd24e9eaee1427f

commit r12-4532-g82cd78f2c31db1664ca154d7fcd24e9eaee1427f
Author: Aldy Hernandez <aldyh@redhat.com>
Date:   Wed Oct 20 09:05:23 2021 +0200

    Restore --param=max-fsm-thread-length

    The removal of --param=max-fsm-thread-length is causing code
    explosion.  I thought that --param=max-fsm-thread-path-insns was a
    better gague for path profitability than raw BB length, but it turns
    out that we don't take into account PHIs when estimating the number of
    statements.

    In this PR, we have a sequence of very large PHIs that have us
    traversing extremely large paths that blow up the compilation.

    We could fix this a couple of different ways.  We could avoid
    traversing more than a certain number of PHI arguments, or ignore
    large PHIs altogether.  The old implementation certainly had this
    knob, and we could cut things off before we even got to the ranger.
    We could also adjust the instruction estimation to take into account
    PHIs, but I'm sure we'll mess something else in the process ;-).

    The easiest thing to do is just restore the knob.

    At a later time we could tweak this further, for instance,
    disregarding empty blocks in the count.  BTW, this is the reason I
    didn't chop things off in the lowlevel registry for all threaders: the
    forward threader can't really explore too deep paths, but it could
    theoretically get there while threading over empty blocks.

    This fixes 102814, 102852, and I bet it solves the Linux kernel cross
    compile issue.

    Tested on x86-64 Linux.

    gcc/ChangeLog:

            PR tree-optimization/102814
            * doc/invoke.texi: Document --param=max-fsm-thread-length.
            * params.opt: Add --param=max-fsm-thread-length.
            * tree-ssa-threadbackward.c
            (back_threader_profitability::profitable_path_p): Fail on paths
            longer than max-fsm-thread-length.

  parent reply	other threads:[~2021-10-20  9:09 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-18 17:32 [Bug tree-optimization/102814] New: " dimhen at gmail dot com
2021-10-18 21:06 ` [Bug tree-optimization/102814] " pinskia at gcc dot gnu.org
2021-10-19  7:20 ` aldyh at gcc dot gnu.org
2021-10-19  7:40 ` rguenth at gcc dot gnu.org
2021-10-19  7:45 ` aldyh at gcc dot gnu.org
2021-10-20  7:10 ` aldyh at gcc dot gnu.org
2021-10-20  7:10 ` aldyh at gcc dot gnu.org
2021-10-20  9:09 ` cvs-commit at gcc dot gnu.org [this message]
2021-10-20  9:10 ` aldyh at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-102814-4-YslJG1QkD0@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).