public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "abel at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling Date: Thu, 24 Jan 2013 13:37:00 -0000 [thread overview] Message-ID: <bug-55889-4-FX6UJNHK1U@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-55889-4@http.gcc.gnu.org/bugzilla/> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889 --- Comment #23 from Andrey Belevantsev <abel at gcc dot gnu.org> 2013-01-24 13:37:05 UTC --- You are right from the target maintainer point of view, as you understand what really happens in the code. But this is not what the compiler sees as the relations between insns you are talking about are not always expressed in the RTL. Consider insns 17 and 23, not looking at the other insns. From their RTL there is no "clear control and data dependencies" at all, they don't mention the same register or memory. (You are saying that insn 17 represents a call but it is not clear from its representation, too.) As I mentioned, the only reason insn 23 gets dependent on insn 17 is that ira_implicitly_set_insn_hard_regs kicks in and says, we have a LINK_REGS alternative in insn 23, and the corresponding reg class is small, let us consider insn 23 clobber reg 65 (LR), and because insn 17 also clobbers reg 65 you get a dependency. This was added with the sched-pressure code, which is why I CC'd Vlad. And this issue is not sel-sched specific, you need just to disable the if (! reload_completed) at sched-deps.c:2805 with e.g. && INSN_UID (insn) != 23, and remove the -fselective-scheduling flag, and you will see the regular scheduler happily lift off insn 23 through insn 17 and place it before insn 17, as there is no dependency that can be guessed by the regular sched-deps analysis just by looking at the RTL of those insns. If you want to have such a dependency, I'd suggest to add some specific clobber as it is done for insn 17. This will fix this particular issue, but in general the question on the register renaming in the sel-sched remains, as we just see 17: r3 = rhs1 20: use(r3) 24: r3 = rhs2 and we assume we can do new1: r150 = rhs2 17: r3 = rhs1 20: use(r3) new2: r3 = r150 and this will not create random dependencies between insn new1 and insn 17 as it happens now. Again, there is no dependencies that can be seen from the RTL that prevent us from doing so.
next prev parent reply other threads:[~2013-01-24 13:37 UTC|newest] Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-01-06 18:55 [Bug middle-end/55889] New: " dje at gcc dot gnu.org 2013-01-06 18:56 ` [Bug middle-end/55889] " dje at gcc dot gnu.org 2013-01-07 15:55 ` rguenth at gcc dot gnu.org 2013-01-08 12:19 ` jakub at gcc dot gnu.org 2013-01-08 21:56 ` dje at gcc dot gnu.org 2013-01-09 2:53 ` dje at gcc dot gnu.org 2013-01-09 14:26 ` abel at gcc dot gnu.org 2013-01-11 14:24 ` abel at gcc dot gnu.org 2013-01-11 14:38 ` dje at gcc dot gnu.org 2013-01-18 11:09 ` abel at gcc dot gnu.org 2013-01-18 16:49 ` dje at gcc dot gnu.org 2013-01-18 16:57 ` dje at gcc dot gnu.org 2013-01-21 10:16 ` abel at gcc dot gnu.org 2013-01-21 12:53 ` jakub at gcc dot gnu.org 2013-01-21 13:24 ` abel at gcc dot gnu.org 2013-01-21 15:14 ` dje at gcc dot gnu.org 2013-01-21 15:16 ` dje at gcc dot gnu.org 2013-01-21 15:25 ` jakub at gcc dot gnu.org 2013-01-21 15:38 ` dje at gcc dot gnu.org 2013-01-21 15:42 ` dje at gcc dot gnu.org 2013-01-21 15:54 ` jakub at gcc dot gnu.org 2013-01-21 17:32 ` abel at gcc dot gnu.org 2013-01-23 11:11 ` abel at gcc dot gnu.org 2013-01-24 2:36 ` dje at gcc dot gnu.org 2013-01-24 13:37 ` abel at gcc dot gnu.org [this message] 2013-01-24 16:37 ` dje at gcc dot gnu.org 2013-01-31 17:50 ` dje at gcc dot gnu.org 2013-02-01 12:22 ` abel at gcc dot gnu.org 2013-02-06 21:38 ` vmakarov at gcc dot gnu.org 2013-02-14 6:11 ` abel at gcc dot gnu.org 2013-02-14 16:48 ` vmakarov at redhat dot com 2013-02-15 13:48 ` abel at gcc dot gnu.org 2013-02-15 16:15 ` dje at gcc dot gnu.org 2013-02-19 13:51 ` abel at gcc dot gnu.org 2013-02-19 13:55 ` abel 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-55889-4-FX6UJNHK1U@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: linkBe 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).