From patchwork Fri Oct 9 21:36:25 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Mike Stump X-Patchwork-Id: 528443 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]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id B7EE2140E3D for ; Sat, 10 Oct 2015 08:38:08 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=lMQOfRNv; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; q=dns; s=default; b=PWfkDZxcanHZeaR2uZp55FwJq+ +tWd17SZcYfxKniOrq+4TAGl6dLArX5GEOUctAPEkR9asn3JyflG3j43XCzkUr+E TgSjnfKDRQMOTeGjfHLY58YBhzlRePG3EpjbOGPcMCPsy/cu4dcY+Ze9rvXYF8tW AQSlXgcts9kK8NWes= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; s=default; bh=mWRHo5jRmuRbRI1k9r53C4zrkds=; b= lMQOfRNvDtIvGUWHDicKL0l0q7m8bNXtDrxlq2O7DLPhZOw31Fzt4NmrELrh6p3u 5F2X8nNJcbvjm4pyS67F0gGqFOGt/KvVBLFOKGQ8/Uos9+gA5YOlat4NKe/aVBIB 7zRmz5CrxyxGDjR/L6pWDmwgZP0i4Jq6ncQ0OWbsyJg= Received: (qmail 10349 invoked by alias); 9 Oct 2015 21:38:02 -0000 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 Received: (qmail 10315 invoked by uid 89); 9 Oct 2015 21:38:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_PASS, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: resqmta-po-03v.sys.comcast.net Received: from resqmta-po-03v.sys.comcast.net (HELO resqmta-po-03v.sys.comcast.net) (96.114.154.162) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 09 Oct 2015 21:38:00 +0000 Received: from resomta-po-17v.sys.comcast.net ([96.114.154.241]) by resqmta-po-03v.sys.comcast.net with comcast id T9dx1r0055Clt1L019dyZE; Fri, 09 Oct 2015 21:37:58 +0000 Received: from [IPv6:2001:558:6045:a4:40c6:7199:cd03:b02d] ([IPv6:2001:558:6045:a4:40c6:7199:cd03:b02d]) by resomta-po-17v.sys.comcast.net with comcast id T9dx1r00F2ztT3H019dyJ9; Fri, 09 Oct 2015 21:37:58 +0000 From: Mike Stump Subject: scheduling conditional branches after stores Message-Id: Date: Fri, 9 Oct 2015 14:36:25 -0700 To: GCC Patches Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-IsSubscribed: yes So, I keep on seeing inaccurate schedule time on the conditional branches after a store, and tracked it down to this type of solution. On my machine, I can run these two in the same cycle, but with a REG_DEP_OUTPUT dependency it was moving the branch to the next cycle. Now, I’ll plead ignorance if this is the right way to fix the issue, but thought I would post it for comment. I kinda wanted a control dependency of some sort, but those seem only to be used for predicated instructions, which doesn’t apply to the case at hand. For the instructions, from my view, there are no data dependencies at all. What dependencies exists is the dependency that one cannot interchange: $r1 = 1 jump L5 neither, can one interchange: $r1 = 1 if ($r2) jump L5 nor: mem[$r1] = 1 if ($r2) jump L5 This last case being the one that I’m interested in. So, the question is, is the below patch the right way to fix this? if (dep_type == REG_DEP_ANTI) cost = 0; else if (dep_type == REG_DEP_OUTPUT) { cost = (insn_default_latency (insn) - insn_default_latency (used)); if (cost <= 0) cost = 1; } diff --git a/gcc/sched-deps.c b/gcc/sched-deps.c index 5434831..1f88734 100644 --- a/gcc/sched-deps.c +++ b/gcc/sched-deps.c @@ -3044,7 +3044,7 @@ sched_analyze_insn (struct deps_desc *deps, rtx x, rtx_insn *insn) { if (! sched_insns_conditions_mutex_p (insn, pending->insn ())) add_dependence (insn, pending->insn (), - REG_DEP_OUTPUT); + REG_DEP_ANTI); pending = pending->next (); pending_mem = pending_mem->next (); }