From patchwork Wed Apr 12 16:10:29 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff Law X-Patchwork-Id: 750063 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 3w386G4tw5z9s8N for ; Thu, 13 Apr 2017 02:10:43 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="hKtHc6zh"; 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 :to:subject:message-id:date:mime-version:content-type; q=dns; s= default; b=XKn+no3d9uiU1i+fPxF3Z0iDUr3cDrC6Wd7mmF8pzC6Nt+3JRla9Q DDLCSwWVPbIyE3NBJV2mbWw2lZItlHEMhViB6xTFqGUYv0hQBs7yp0gXvqQeR5aY gYBvPm50fGEPWUh7MwWrleqrvV3UijhP1Pt95MLqkKiw9Nj3KiNhiQ= 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 :to:subject:message-id:date:mime-version:content-type; s= default; bh=U6dnhOcF5aCtMLBY0jCZZeCahR0=; b=hKtHc6zhp28GpYv3Dzxb TOOO9Ko8A3ZOB0xuihr6Rajqh4tbPHcQ4IaB+ZN1dasrlGpTlL6xqTA72ky6WMF0 J2/QAA8M2hxi65+l9jjO/Tgh5tet1zShEFiU3Z95DfCx3+AceGHjb8mYtcEjrAi1 Bhgfal0ijJIKAvEZiY4iiHg= Received: (qmail 52929 invoked by alias); 12 Apr 2017 16:10:32 -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 52361 invoked by uid 89); 12 Apr 2017 16:10:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RP_MATCHES_RCVD, SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=recollection, Hx-languages-length:2796 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 12 Apr 2017 16:10:30 +0000 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8F750635F0 for ; Wed, 12 Apr 2017 16:10:30 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 8F750635F0 Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=law@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 8F750635F0 Received: from localhost.localdomain (ovpn-116-10.phx2.redhat.com [10.3.116.10]) by smtp.corp.redhat.com (Postfix) with ESMTP id DC9BA8864A for ; Wed, 12 Apr 2017 16:10:29 +0000 (UTC) From: Jeff Law To: gcc-patches Subject: Fix SH port failure in delay slot scheduling Message-ID: <39407793-4668-f15f-facb-3cd7ecda1c9e@redhat.com> Date: Wed, 12 Apr 2017 10:10:29 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 X-IsSubscribed: yes The SH port has this delay slot description like this: ;; Conditional branches with delay slots are available starting with SH2. ;; If zero displacement conditional branches are fast, disable the delay ;; slot if the branch jumps over only one 2-byte insn. (define_delay (and (eq_attr "type" "cbranch") (match_test "TARGET_SH2") (not (and (match_test "TARGET_ZDCBRANCH") (match_test "sh_cbranch_distance (insn, 4) == 2")))) [(eq_attr "cond_delay_slot" "yes") (nil) (nil)]) What's interesting here is whether or not a particular insn has a delay slot is dependent on nearby insns *and* it can change within the reorg pass itself. This can cause assert failures within write_eligible_for_delay. It's been 20+ years since I was deep into the delay slot scheduler, but my recollection is this doesn't consistently work and I could argue that this delay slot description is fundamentally broken. While I can fix this specific assertion failure, I would not at all be surprised if there's other issues lurking. The port maintainers should be on notice that this description may need to be adjusted in the future to remove the distance test. Addressing this specific failure can be done by verifying the given insn still has a delay slot in eligible_for_delay*. That's enough to get the SH to build libgcc/newlib. I've also verified other ports that use delay slots such as the PA & Sparc can build glibc and newlib as appropriate. Installing on the trunk. Jeff commit 294e866ca9e7e59f5cd637e5b746828c614e6bc5 Author: law Date: Wed Apr 12 16:08:18 2017 +0000 * genattrtab.c (write_eligible_delay): Verify DELAY_INSN still has a delay slot in the generated code. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@246879 138bc75d-0d04-0410-961f-82ee72b054a4 diff --git a/gcc/ChangeLog b/gcc/ChangeLog index fc0becf..89af9cc 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,5 +1,8 @@ 2017-04-12 Jeff Law + * genattrtab.c (write_eligible_delay): Verify DELAY_INSN still + has a delay slot in the generated code. + * config/cris/cris.md (cris_preferred_reload_class): Return GENNONACR_REGS rather than GENERAL_REGS. diff --git a/gcc/genattrtab.c b/gcc/genattrtab.c index cd4e668..3629b5f 100644 --- a/gcc/genattrtab.c +++ b/gcc/genattrtab.c @@ -4416,6 +4416,9 @@ write_eligible_delay (FILE *outf, const char *kind) fprintf (outf, "{\n"); fprintf (outf, " rtx_insn *insn ATTRIBUTE_UNUSED;\n"); fprintf (outf, "\n"); + fprintf (outf, " if (num_delay_slots (delay_insn) == 0)\n"); + fprintf (outf, " return 0;"); + fprintf (outf, "\n"); fprintf (outf, " gcc_assert (slot < %d);\n", max_slots); fprintf (outf, "\n"); /* Allow dbr_schedule to pass labels, etc. This can happen if try_split