From patchwork Tue Feb 13 03:09:44 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff Law X-Patchwork-Id: 872552 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-473130-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="nCiMe8mK"; 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 3zgSFd5Jxfz9sPk for ; Tue, 13 Feb 2018 14:09:56 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:to :from:subject:message-id:date:mime-version:content-type; q=dns; s=default; b=vFMGv9o8pqNnYNGyprqg3ugZzPjRSHsxafKEMrCCYWoV6V4Czb WgRqEdtmgDcH91o8Ylo0IrhkVID+xFjWVfSEdapeoCR7XifXGqieSOJWayK+b7kw +Sj89tXXpH+IX78qFQXEZtcn0G3ZrTgj/klkxLX91Y2fHAY4VVw2GC1Mg= 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:to :from:subject:message-id:date:mime-version:content-type; s= default; bh=O06kEJ9qytdJvXltzS3FprXopBU=; b=nCiMe8mKzfiAR76XdSSN QDPuyniJAL5zpCTl+Xyqy9R3QsZFuWI5MPoVhuY6bdAkI7hK1QayTVwdPjngRK24 cEcNDPNPW5O5yS/wnmHMYIglSNrnp+yQQkTcC4tqGpmE48QZnA9d6+ye7qxnZUBg YSY/pxbCy5pqIjH+fPGxmeQ= Received: (qmail 35646 invoked by alias); 13 Feb 2018 03:09:49 -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 35634 invoked by uid 89); 13 Feb 2018 03:09:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-25.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, KAM_LAZY_DOMAIN_SECURITY, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=sensitivity, collateral, HX-Greylist:Tue, shelf 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; Tue, 13 Feb 2018 03:09:47 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1C7F87F755 for ; Tue, 13 Feb 2018 03:09:46 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-36.rdu2.redhat.com [10.10.112.36]) by smtp.corp.redhat.com (Postfix) with ESMTP id 64E5760621 for ; Tue, 13 Feb 2018 03:09:45 +0000 (UTC) To: gcc-patches From: Jeff Law Subject: [PATCH][committed][PR target/83760] Fix several instances of maybe_record_trace_start ICEs on sh Message-ID: <3c47469f-c8c0-4daa-aa44-7b38da408727@redhat.com> Date: Mon, 12 Feb 2018 20:09:44 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 X-IsSubscribed: yes The SH port has a pass which looks for suitable places to put its constant table. Ideally it finds a barrier (within a certain range from the first use of the pool) and shoves the constant pool after that barrier. Otherwise it'll create jump/barrier/ style sequence and insert the constant pool after the barrier, but before the jump target. That's all fine and good. Except that it can confuse the CFI machinery. The sequence makes it look like there's live code after the sibling call. It's now so clear why this bug came and went semi-randomly across the various sh targets -- it depends on the sibling call being the insn which causes the main loop in find_barrier to exit. So one more or one less insn, or an insn changing alternative (and thus size) and the bug goes latent. Anyway fixing this is pretty simple. We can just insert the table after the sibling call (taking care not to separate the call from its NOTE_INSN_CALL_ARG_LOCATION note). I went back and verified each of the SH bugs where we had testcases for this problem were fixed by this patch. I also verified that the sh-elf libgcc/newlib targets built after this patch. Given the sensitivity to precisely what insn causes the loop to exit, I haven't bothered to add a test to the testsuite. This would likely be a reasonable backport candidate to gcc-7 if SH folks are interested. Installed onto the trunk, Jeff ps. No, I wasn't really looking to fix the SH stuff. I'm really chasing that MIPS regression. Fixing this was just collateral damage. commit eeace813c643ee2f2c5f37bf984a680be6032a2d Author: law Date: Tue Feb 13 03:07:04 2018 +0000 PR target/83760 * config/sh/sh.c (find_barrier): Consider a sibling call a barrier as well. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@257611 138bc75d-0d04-0410-961f-82ee72b054a4 diff --git a/gcc/ChangeLog b/gcc/ChangeLog index d5913d0a7db..a74c8610443 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,5 +1,9 @@ 2018-02-12 Jeff Law + PR target/83760 + * config/sh/sh.c (find_barrier): Consider a sibling call + a barrier as well. + * cse.c (try_back_substitute_reg): Move any REG_ARGS_SIZE note when successfully back substituting a reg. diff --git a/gcc/config/sh/sh.c b/gcc/config/sh/sh.c index 48e99a3cadf..90d6c733d33 100644 --- a/gcc/config/sh/sh.c +++ b/gcc/config/sh/sh.c @@ -5233,10 +5233,22 @@ find_barrier (int num_mova, rtx_insn *mova, rtx_insn *from) CALL_ARG_LOCATION note. */ if (CALL_P (from)) { + bool sibcall_p = SIBLING_CALL_P (from); + rtx_insn *next = NEXT_INSN (from); if (next && NOTE_P (next) && NOTE_KIND (next) == NOTE_INSN_CALL_ARG_LOCATION) from = next; + + /* If FROM was a sibling call, then we know that control + will not return. In fact, we were guaranteed to hit + a barrier before another real insn. + + The jump around the constant pool is unnecessary. It + costs space, but more importantly it confuses dwarf2cfi + generation. */ + if (sibcall_p) + return emit_barrier_after (from); } from = emit_jump_insn_after (gen_jump (label), from);