From patchwork Sat Oct 29 19:17:30 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tom de Vries X-Patchwork-Id: 122557 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 3089DB6F76 for ; Sun, 30 Oct 2011 06:18:09 +1100 (EST) Received: (qmail 5128 invoked by alias); 29 Oct 2011 19:18:08 -0000 Received: (qmail 5119 invoked by uid 22791); 29 Oct 2011 19:18:07 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 29 Oct 2011 19:17:45 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1RKEPY-0006Mk-18 from Tom_deVries@mentor.com ; Sat, 29 Oct 2011 12:17:44 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 29 Oct 2011 12:16:48 -0700 Received: from [127.0.0.1] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.1.289.1; Sat, 29 Oct 2011 20:17:42 +0100 Message-ID: <4EAC514A.2090607@mentor.com> Date: Sat, 29 Oct 2011 21:17:30 +0200 From: Tom de Vries User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: Richard Henderson CC: "gcc-patches@gcc.gnu.org" Subject: [PR50764, PATCH] Fix for ICE in maybe_record_trace_start with -fsched2-use-superblocks Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Richard, I have a tentative fix for PR50764. In the example from the test-case, -fsched2-use-superblocks moves an insn from block 4 to block 3. 2 bar | -------+----- / \ * * 5 *------------ 3 abort bar | | * 4 return The insn has a REG_CFA_DEF_CFA note and is frame-related. ... (insn/f 51 50 52 4 (set (reg:DI 39 r10) (mem/c:DI (plus:DI (reg/f:DI 6 bp) (const_int -8 [0xfffffffffffffff8])) [3 S8 A8])) pr50764.c:13 62 {*movdi_internal_rex64} (expr_list:REG_CFA_DEF_CFA (reg:DI 39 r10) (nil))) ... This causes the assert in maybe_record_trace_start to trigger: ... /* We ought to have the same state incoming to a given trace no matter how we arrive at the trace. Anything else means we've got some kind of optimization error. */ gcc_checking_assert (cfi_row_equal_p (cur_row, ti->beg_row)); ... The assert does not occur with -fno-tree-tail-merge, but that is due to the following: - -fsched-use-superblocks does not handle dead labels explicitly - -freorder-blocks introduces a dead label, which is not removed until after sched2 - -ftree-tail-merge makes a difference in which block -freorder-blocks introduces the dead label. In the case of -ftree-tail-merge, the dead label is introduced at the start of block 3, and block 3 and 4 end up in the same ebb. In the case of -fno-tree-tail-merge, the dead label is introduced at the start of block 4, and block 3 and 4 don't end up in the same ebb. attached untested patch fixes PR50764 in a similar way as the patch for PR49994, which is also about an ICE in maybe_record_trace_start with -fsched2-use-superblocks. The patch for PR49994 makes sure frame-related instructions are not moved past the following jump. Attached patch makes sure frame-related instructions are not moved past the preceding jump. Is this the way to fix this PR? Thanks, - Tom 2011-10-29 Tom de Vries PR rtl-optimization/50764 * (sched_analyze_insn): Make sure frame-related insns are not moved past preceding jump. Index: gcc/sched-deps.c =================================================================== --- gcc/sched-deps.c (revision 180521) +++ gcc/sched-deps.c (working copy) @@ -2812,8 +2812,13 @@ sched_analyze_insn (struct deps_desc *de during prologue generation and avoid marking the frame pointer setup as frame-related at all. */ if (RTX_FRAME_RELATED_P (insn)) - deps->sched_before_next_jump - = alloc_INSN_LIST (insn, deps->sched_before_next_jump); + { + deps->sched_before_next_jump + = alloc_INSN_LIST (insn, deps->sched_before_next_jump); + + if (deps->pending_jump_insns) + add_dependence (insn, XEXP (deps->pending_jump_insns, 0), REG_DEP_ANTI); + } if (code == COND_EXEC) {