From patchwork Tue Nov 6 20:58:33 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bernd Schmidt X-Patchwork-Id: 197541 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 CD47F2C00BA for ; Wed, 7 Nov 2012 07:58:58 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1352840340; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:Sender:Delivered-To; bh=phYXgK+ eLEDgxZ+ZcJg8LpWf6rA=; b=SaJna5uPhI0u3qM3eqpTXNmMWPq0G9x0CMeTaO5 iO/YgoM9QcEDnDSy82PKncaw3ehobvwi101wzQclJUkhpUDiJYEAIV8oXYcHSwc1 UEvSXMzIp4Ro9PzmT/q51HDRz/gPC9swNtQoKNsu3VoZwX8Au6qt+PFTjUG1vo2d pBxY= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=F04YYo4Ms/p6QXInpgpMD1nbwsQkol0s5QNyXf4FeNaSe6I6hJf8Wi4SzoZKU/ xn0zvFVsYwq++KEjiGX9CMVGWrjb/XrG2Q21SOGWnfrHmnkAHJp4n1yiF0ToDk1l ewhhupyAZt/khhJYr87Q/7Os06lhDZJdowWd+5kNiMSUU=; Received: (qmail 11139 invoked by alias); 6 Nov 2012 20:58:54 -0000 Received: (qmail 11130 invoked by uid 22791); 6 Nov 2012 20:58:53 -0000 X-SWARE-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL, BAYES_00, FROM_12LTRDOM, KHOP_RCVD_UNTRUST, RCVD_IN_HOSTKARMA_W, RCVD_IN_HOSTKARMA_WL 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; Tue, 06 Nov 2012 20:58:48 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1TVqER-0000JN-3K from Bernd_Schmidt@mentor.com for gcc-patches@gcc.gnu.org; Tue, 06 Nov 2012 12:58:47 -0800 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Nov 2012 12:58:46 -0800 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; Tue, 6 Nov 2012 20:58:44 +0000 Message-ID: <509979F9.10507@codesourcery.com> Date: Tue, 6 Nov 2012 21:58:33 +0100 From: Bernd Schmidt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.10) Gecko/20121104 Thunderbird/10.0.10 MIME-Version: 1.0 To: GCC Patches Subject: sched-deps patch: Fix PR54580 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 If we have i1: [r1 + 24] = x i2: r1 = r1 + 24; i3: y = [r1] then, if not using cselib, we do not generate a dependency between i3 and i1, since we compare memory addresses [r1] and [r1 + 24]. This is somewhat lame, but safe since i2 depends on i1 and i3 depends on i2. However, it breaks with the new optimization I've recently added, which allows us to switch i3 and i2 by modifying the address in i3. We can end up with i3: y = [r1 + 24] i1: [r1 + 24] = x i2: r1 = r1 + 24 which is incorrect. The following patch is a conservative way of fixing this by simply transferring all backwards dependencies from i2 to i3. I thought about trying to do better when using cselib for a while, but I wasn't quite certain how flush_pending_lists would interact with this, and it almost certainly doesn't really matter. Bootstrapped and tested on x86_64-linux (boehm-gc.c/gctest.c appears to fail randomly, otherwise no changes). Ok? Bernd * sched-deps.c (find_inc): Add all dependencies from the inc_insn to the mem_insn. Index: sched-deps.c =================================================================== --- sched-deps.c (revision 191838) +++ sched-deps.c (working copy) @@ -4706,16 +4706,14 @@ find_inc (struct mem_inc_info *mii, bool if (backwards) { FOR_EACH_DEP (mii->inc_insn, SD_LIST_BACK, sd_it, dep) - if (modified_in_p (mii->inc_input, DEP_PRO (dep))) - add_dependence_1 (mii->mem_insn, DEP_PRO (dep), - REG_DEP_TRUE); + add_dependence_1 (mii->mem_insn, DEP_PRO (dep), + REG_DEP_TRUE); } else { FOR_EACH_DEP (mii->inc_insn, SD_LIST_FORW, sd_it, dep) - if (modified_in_p (mii->inc_input, DEP_CON (dep))) - add_dependence_1 (DEP_CON (dep), mii->mem_insn, - REG_DEP_ANTI); + add_dependence_1 (DEP_CON (dep), mii->mem_insn, + REG_DEP_ANTI); } return true; }