From patchwork Thu Jul 13 22:00:48 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jim Wilson X-Patchwork-Id: 788003 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 3x7qX74m7dz9s06 for ; Fri, 14 Jul 2017 08:01:11 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="VRfyqzUz"; 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 :mime-version:from:date:message-id:subject:to:cc:content-type; q=dns; s=default; b=dqSVS2NX49bIurCg8jmdwy73Eqqt6PzdFv5MGpCF6hm l3TeMPeRxBGSS3lhLYPDLWGWczK3BhQav7Y3nU1oIestMy5wpcjh6RCVo09SH8jJ RyA+PWtQK4wCDuBzmvS0YSiy3YNw0VFD8dD7Te5OoR1haEsQEj9J+6fJ+tJKHlhc = 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 :mime-version:from:date:message-id:subject:to:cc:content-type; s=default; bh=N2Ub6E6PcqsQMbsfS0BXhxmPKms=; b=VRfyqzUzZyV2ZynDh 4F0y4XWDX3jq1ICLfThX4/OANLYXAF2LEuwcpW9QGkTNfV621tKYlziKDQJcipl9 bvvew0ipKWHbRL4HTKTd2bhbMSmNbs6XorHDjTgjWgQi7BvN5diDK9mZ0kZJFBMU 9GFPgsMdSQ6hjS0w7DAApIqzRo= Received: (qmail 117462 invoked by alias); 13 Jul 2017 22:01:00 -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 117345 invoked by uid 89); 13 Jul 2017 22:00:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-24.8 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM, SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:2532, 63307 X-HELO: mail-lf0-f41.google.com Received: from mail-lf0-f41.google.com (HELO mail-lf0-f41.google.com) (209.85.215.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 13 Jul 2017 22:00:52 +0000 Received: by mail-lf0-f41.google.com with SMTP id b207so44207847lfg.2 for ; Thu, 13 Jul 2017 15:00:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=vB/W5Hi25+3l3otCQlNpL5UWvCsAfFLW9TOGjxUex+A=; b=a43IgVr3SqD/X7ogBnpOMh2OiaEnQiDKrQ5BHa5c2GL4V0xeNB9mjru+wuGPzw41VP dzvojtJVVKWLwAe+v0uJOUJ9Vlymn7grZfWw70AD6SARaFusOY0jcOsKnDJKvox8gc39 cW30PQtti7enN13vmt45RoSZBh/3XTTq5Asz+KmWytX+I/s6YCxj+CmC735jT22Wqd5W D7G63L7tzfT1bgbuQBdcWX1NiRbJ6v743SQstEZmsbDJLFXCcHtD3m/39/InhG6DJvNd rCDJ8Fx34SnldySwcuUjiQxnMT7xDMMyqBPW6+BGDcwNhamDW1EbF5aQPbqtE1r5azmD V+Eg== X-Gm-Message-State: AIVw112XzoHJ550OHIq1Ljwu+saeKgYty2bGYO1QJUnLmAD4k2okraOl PsQyFLQhrhayjqj2xR1FEPCqu+0z4DWO9cNHMw== X-Received: by 10.25.229.13 with SMTP id c13mr2047082lfh.102.1499983249401; Thu, 13 Jul 2017 15:00:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.87.82 with HTTP; Thu, 13 Jul 2017 15:00:48 -0700 (PDT) From: Jim Wilson Date: Thu, 13 Jul 2017 15:00:48 -0700 Message-ID: Subject: [PATCH] scheduler bug fix for AArch64 insn fusing SCHED_GROUP usage To: "gcc-patches@gcc.gnu.org" Cc: Jim Wilson The AArch64 port uses SCHED_GROUP to mark instructions that get fused at issue time, to ensure that they will be issued together. However, in the scheduler, use of a SCHED_GROUP forces all other instructions to issue in the next cycle. This is wrong for AArch64 ports using insn fusing which can issue multiple insns per cycle, as aarch64 SCHED_GROUP insns can all issue in the same cycle, and other insns can issue in the same cycle also. I put a testcase and some info in bug 81434. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81434 The attached patch fixes the problem. The behavior in pass == 0 is same as now. All non sched group insns are ignored, and all sched group insns are checked to see if they need to be queued for a latter cycle. The difference is in the second pass where non sched group insns are queued for a latter cycle only if there is a sched group insn that got queued. Since sched group insns always sort to the top of the list of insns to schedule, all sched group insns still get scheduled together as before. This has been tested with an Aarch64 bootstrap and make check. OK? Jim 2017-07-13 Jim Wilson PR rtl-optimization/81434 * haifa-sched.c (prune_ready_list): Init min_cost_group to 0. Update comment for main loop. In sched_group_found if, also add checks for pass and min_cost_group. diff --git a/gcc/haifa-sched.c b/gcc/haifa-sched.c index 1b13e32..f6369d9 100644 --- a/gcc/haifa-sched.c +++ b/gcc/haifa-sched.c @@ -6300,7 +6300,7 @@ prune_ready_list (state_t temp_state, bool first_cycle_insn_p, { int i, pass; bool sched_group_found = false; - int min_cost_group = 1; + int min_cost_group = 0; if (sched_fusion) return; @@ -6316,8 +6316,8 @@ prune_ready_list (state_t temp_state, bool first_cycle_insn_p, } /* Make two passes if there's a SCHED_GROUP_P insn; make sure to handle - such an insn first and note its cost, then schedule all other insns - for one cycle later. */ + such an insn first and note its cost. If at least one SCHED_GROUP_P insn + gets queued, then all other insns get queued for one cycle later. */ for (pass = sched_group_found ? 0 : 1; pass < 2; ) { int n = ready.n_ready; @@ -6330,7 +6330,8 @@ prune_ready_list (state_t temp_state, bool first_cycle_insn_p, if (DEBUG_INSN_P (insn)) continue; - if (sched_group_found && !SCHED_GROUP_P (insn)) + if (sched_group_found && !SCHED_GROUP_P (insn) + && ((pass == 0) || (min_cost_group >= 1))) { if (pass == 0) continue;