From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15510 invoked by alias); 14 Feb 2013 06:11:55 -0000 Received: (qmail 15451 invoked by uid 48); 14 Feb 2013 06:11:26 -0000 From: "abel at gcc dot 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, 14 Feb 2013 06:11:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: abel at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: abel at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.8.0 X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2013-02/txt/msg01386.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889 --- Comment #28 from Andrey Belevantsev 2013-02-14 06:11:21 UTC --- (In reply to comment #27) > (In reply to comment #26) > > You are right, your suggestions is what I sketched in comment #21 as choices 1 > > or 2. Sorry for my unclear expalanation of what was actually happening. > > > > I don't have a problem with making sel-sched have extra checks when renaming > > registers before reload, which will make us notice a not obvious extra > > dependence and avoid renaming properly, as now we've figured out these > > dependences don't follow immediately from the RTL. I just want an extra > > opinion on whether such unexpected dependencies arising when a target (hard) > > register is replaced by a pseudo register should be normal within GCC, or do we > > attribute such dependencies only to the register pressure scheduling mode. > > FWIW, I would rather agree with the latter than with the former. > > I guess you can not fully assume that dependencies are created only from RTL > data flow. There are cases (besides pressure sensitive scheduling case > mentioned here) when dependencies are still created for other reasons different > from RTL data flow. I'd look at the dependencies as constraints resulting in > correct and *desirable* insn schedule. Although overwhelming majority of them > are created from RTL data flow analysis. I agree with you in general, it's just this case of having extra dependencies because an LHS hard register was substituted to a pseudo is non-intuitive to me. I am not aware of other similar cases when the "other dependency reasons" you mention kick in after such transformation. So I'll try going with the minimal fix of tracking only this particular case (of newly created implicit clobbers) in the selective scheduler. Btw, does the code calculating implicit clobbers via ira_implicitly_set_insn_hard_regs were planned just for the pressure sensitive scheduling or also for the general case? It looks like it is needed for the former but it is calculated for the latter.