From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30348 invoked by alias); 4 Feb 2014 11:44:28 -0000 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 Received: (qmail 30318 invoked by uid 48); 4 Feb 2014 11:44:24 -0000 From: "abel at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/56885] [4.8/4.9 Regression] ICE: in assign_by_spills, at lra-assigns.c:1268 with -O -fschedule-insns -fselective-scheduling Date: Tue, 04 Feb 2014 11:44:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: abel at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.8.3 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-02/txt/msg00284.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56885 Andrey Belevantsev changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |abel at gcc dot gnu.org --- Comment #9 from Andrey Belevantsev --- Trunk does not ICE for me anymore, though the two insns Yuri mentioned are still reordered. I will explain what happens in more detail. The selective scheduler supports register renaming. So on seeing an anti-dependence in this case for di=r69 it assumes that the RHS of this insn can be moved up with the new register, e.g. r?? = r69 and later di = r??. When the new register is being chosen, there is nothing in the function that prevents using the original register, di -- no liveness or hardware imposed restrictions are reported by the backend so we allow to move the insn with the original register. The reason for this is that the dependence comes from the implicit_set on the another insn (insn 30 in Yuri's dump), and implicit sets do not get reflected in the dataflow information (which we get from DF_LIVE_IN sets and df_simulate_one_insn_backwards interfaces). Now, if the extra dependencies really come from the evaluation_hook interface of the x86 backend, I'd note that the hook, originally implemented for ia64 only, was not intended for adding any new dependencies, but rather for reflecting the dependencies added in the backend for its own purposes. E.g. for ia64 the interface allows to get the complete dependence picture before making decisions on bundling. So I'd claim that any dependencies created for the scheduler should also be calculated via the general deps_analyze_insn mechanism of sched-deps.c, with the correctly prepared deps context. E.g. any changes done with implicit_sets/clobbers/uses and IRA/LRA interfaces are also visible within the selective scheduling. The selective scheduling analyzes dependencies between separate insns, not blocks, so the evaluation_hook interface does not make sense for it. To summarize, if the backend wants to stop reordering insns in question and also forbid renaming, then this should be exposed from within a hook called from sched-deps.c when calculating dependencies through deps_analyze_insn, not later, and then we can judge whether the new dependence comes from LHS/RHS/whole insn and make appropriate changes for renaming. The current interface does not tell us that renaming is prohibited and we cannot derive it from the IR. The best way would be to properly reflect all restrictions in the IR and not end up lying to the dataflow machinery and the scheduler.