From patchwork Thu Oct 4 15:54:56 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Robin Dapp X-Patchwork-Id: 979025 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-486978-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=linux.ibm.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="SFPqSCRo"; dkim-atps=neutral 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 42QyC94cvyz9s7W for ; Fri, 5 Oct 2018 01:55:16 +1000 (AEST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :subject:to:date:mime-version:content-type :content-transfer-encoding:message-id; q=dns; s=default; b=CfUKg 2o718QA2KClsbCWTIRPEj7QabPal3VAhM1HkevnTXwU1CB9FgNSyFTKoOGeJMFyD u7lDVqKARS3rGyw6TRim74D/aqATR7PsdCB+pwrWOJRyy1+xTSSPDl+AwmYplgwm 5WrNiSTl7LcNMbvn0OYPD3wmt1UTXHPWuG4VRc= 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 :subject:to:date:mime-version:content-type :content-transfer-encoding:message-id; s=default; bh=Bc/WoqXiNl5 gGBsZtSv5JL/MifY=; b=SFPqSCRo+p/qal5XkQOJ8q103CIB2IcDfXhbXvjUQ6F Y+MjIrnQ+55QqqzFczyd7Fg93HZKhx2uz1ET8DvEMsctVsew6/XxX1T/3cjnqioc sWsxft1hpbdoDwOtNJUNyACzNpo5X+b+i1VjEvxjxpnJ63K6ZKqv3BDCdEuMuBzU = Received: (qmail 123221 invoked by alias); 4 Oct 2018 15:55:08 -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 123096 invoked by uid 89); 4 Oct 2018 15:55:07 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-27.6 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, KHOP_DYNAMIC, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 spammy=r7, robin, Actually, opinions X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0b-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.158.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 04 Oct 2018 15:55:06 +0000 Received: from pps.filterd (m0098419.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w94Fsx2A104884 for ; Thu, 4 Oct 2018 11:55:04 -0400 Received: from e06smtp01.uk.ibm.com (e06smtp01.uk.ibm.com [195.75.94.97]) by mx0b-001b2d01.pphosted.com with ESMTP id 2mwmtpbcwk-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 04 Oct 2018 11:55:03 -0400 Received: from localhost by e06smtp01.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 4 Oct 2018 16:55:01 +0100 Received: from b06cxnps3074.portsmouth.uk.ibm.com (9.149.109.194) by e06smtp01.uk.ibm.com (192.168.101.131) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Thu, 4 Oct 2018 16:54:58 +0100 Received: from d06av24.portsmouth.uk.ibm.com (mk.ibm.com [9.149.105.60]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w94FsvYP64815244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 4 Oct 2018 15:54:58 GMT Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6ED2642047 for ; Thu, 4 Oct 2018 18:54:37 +0100 (BST) Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 25F6142042 for ; Thu, 4 Oct 2018 18:54:37 +0100 (BST) Received: from oc6142347168.ibm.com (unknown [9.145.191.1]) by d06av24.portsmouth.uk.ibm.com (Postfix) with ESMTPS for ; Thu, 4 Oct 2018 18:54:37 +0100 (BST) From: Robin Dapp Subject: sched2 priorities and replacements To: GCC Patches Date: Thu, 4 Oct 2018 17:54:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 x-cbid: 18100415-4275-0000-0000-000002C505E2 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18100415-4276-0000-0000-000037D01EE9 Message-Id: Hi, I'm working on some insn latency changes in the s390 backend and noticed a regression in the SPEC2006 bzip2 test case that was due to some insns being scheduled differently. The sequence in short form before my change is ;; | insn | prio | ;; | 823 | 1 | %r1=%r1+0x1 nothing ;; | 420 | 1 | %r3=zxn([%r1]) nothing ;; | 422 | 1 | [%r1]=%r7 nothing ;; | 421 | 0 | %r4=%r3 nothing ;; | 423 | 0 | %r7=%r3 nothing ;; | 428 | 0 | {pc={(%r6!=%r3)?L424:pc};clobber %cc;} nothing sched2 detects a memory inc/ref that can be changed in order to get rid of the dependency 823 -> 420. After that insn 420 is selected and the same happens for insn 422 before insn 823 is scheduled at third position. Actually, what promotes 420 to the first position in the ready queue is not the priority but some of the tie breakers. Now, after my change the situation looks like: ;; | insn | prio | ;; | 825 | 6 | %r1=%r1+0x1 nothing ;; | 420 | 4 | %r3=zxn([%r1]) nothing ;; | 422 | 3 | [%r1]=%r5 nothing ;; | 421 | 0 | %r4=%r3 nothing ;; | 423 | 0 | %r5=%r3 nothing ;; | 428 | 0 | {pc={(%r7!=%r3)?L424:pc};clobber %cc;} nothing ;; --------------- forward dependences: ------------ The same inc/ref as before is detected but insn 825 still has the highest priority and will be selected in the next cycle. Subsequently, the replacement is reverted and insn 420, 422 are scheduled. This introduces a data dependency 825 -> 420 that wasn't there before. In haifa-sched.c:apply_replacement (), after applying the replacement, the dependent insn (420) is updated and its scheduling properties are reset. Nothing happens with insn 825 however. I would have expected that its priority should be recomputed after breaking a dependency since it is recursively determined by the priority of the dependent insns. As a quick hack, I did which prompts a recomputation of 825's priority and helps with my regression (but doesn't get rid of it completely). I haven't checked any other test case but wanted to hear some opinions first. This looks really basic and I'm rather sure I missed some other scheduling part that could deal with this kind of situation. Would somebody mind elucidating? Regards Robin diff --git a/gcc/haifa-sched.c b/gcc/haifa-sched.c index 1fdc9df9fb2..1340f34ed9f 100644 --- a/gcc/haifa-sched.c +++ b/gcc/haifa-sched.c @@ -4713,7 +4713,18 @@ apply_replacement (dep_t dep, bool immediately) success = validate_change (desc->insn, desc->loc, desc->newval, 0); gcc_assert (success); + rtx_insn *insn = DEP_PRO (dep); + INSN_PRIORITY_STATUS (insn) = -1; + sd_iterator_def sd_it; + sd_it = sd_iterator_start (insn, SD_LIST_FORW); + while (sd_iterator_cond (&sd_it, &dep)) + { + DEP_COST (dep) = UNKNOWN_DEP_COST; + sd_iterator_next (&sd_it); + } + priority (insn); update_insn_after_change (desc->insn); + if ((TODO_SPEC (desc->insn) & (HARD_DEP | DEP_POSTPONED)) == 0) fix_tick_ready (desc->insn);