From patchwork Wed Feb 13 23:08:21 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Aaron Sawdey X-Patchwork-Id: 1041688 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-496053-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=linux.ibm.com 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 440FZM4y0Nz9rxp for ; Thu, 14 Feb 2019 10:08:37 +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:date:mime-version:content-type :content-transfer-encoding:message-id; q=dns; s=default; b=wblgB Nds6JmLhNUB/eOh0r9x4L8uUDUdLEg4dZ62nS9ArUtadh5z0PHFKKm54O5POxvi7 6vnKrYTvttyDKxvWjuy4ruBbAC2vijw46joyzkOzoRlh4Qg2OfkZ6av7NbfUDpsI 8SmnEAbHQNQoDmVTMXHLMT/wHFQ9czQFqoW890= 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:date:mime-version:content-type :content-transfer-encoding:message-id; s=default; bh=izDmEqoV2RS 7NbDd1gJ/gM9nqWk=; b=gR2C7QC8SntgUxRdIWWetWeQdkPIze59wVYAHr+TrfI DiK1JbMTBVYv75Bx1N5IKnRQuIyUpuYhIapCEAuin300tRLmGD3mAcirBPcIhqRt mSMLnu1I92beTNI9rMpKKAMOgPVHh9RJBXLptcmFJ952erDi6n5L0ZlRDB27LxOk = Received: (qmail 62615 invoked by alias); 13 Feb 2019 23:08:30 -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 62606 invoked by uid 89); 13 Feb 2019 23:08:29 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-12.6 required=5.0 tests=BAYES_00, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 spammy=aaron, Aaron, HTo:U*ebotcazou 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; Wed, 13 Feb 2019 23:08:28 +0000 Received: from pps.filterd (m0098420.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x1DMxRnM104437 for ; Wed, 13 Feb 2019 18:08:26 -0500 Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by mx0b-001b2d01.pphosted.com with ESMTP id 2qmt7dx64p-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 13 Feb 2019 18:08:26 -0500 Received: from localhost by e35.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 13 Feb 2019 23:08:25 -0000 Received: from b03cxnp08028.gho.boulder.ibm.com (9.17.130.20) by e35.co.us.ibm.com (192.168.1.135) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Wed, 13 Feb 2019 23:08:23 -0000 Received: from b03ledav001.gho.boulder.ibm.com (b03ledav001.gho.boulder.ibm.com [9.17.130.232]) by b03cxnp08028.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x1DN8Mkn22806548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 13 Feb 2019 23:08:22 GMT Received: from b03ledav001.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 99AB26E052; Wed, 13 Feb 2019 23:08:22 +0000 (GMT) Received: from b03ledav001.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 43DFA6E054; Wed, 13 Feb 2019 23:08:22 +0000 (GMT) Received: from ragesh4.rchland.ibm.com (unknown [9.10.86.179]) by b03ledav001.gho.boulder.ibm.com (Postfix) with ESMTP; Wed, 13 Feb 2019 23:08:22 +0000 (GMT) To: gcc-patches@gcc.gnu.org, Segher Boessenkool , Bill Schmidt , David Edelsohn , ebotcazou@libertysurf.fr, rguenther@suse.de From: Aaron Sawdey Subject: [PATCH] PR rtl-optimization/88308 Update LABEL_NUSES in move_insn_for_shrink_wrap Date: Wed, 13 Feb 2019 17:08:21 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 x-cbid: 19021323-0012-0000-0000-0000170A8721 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00010591; HX=3.00000242; KW=3.00000007; PH=3.00000004; SC=3.00000279; SDB=6.01160658; UDB=6.00605791; IPR=6.00941213; MB=3.00025570; MTD=3.00000008; XFM=3.00000015; UTC=2019-02-13 23:08:25 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19021323-0013-0000-0000-000056322CD5 Message-Id: <4ad69547-67df-f989-331c-4111d29fcace@linux.ibm.com> X-IsSubscribed: yes I've tracked pr/88308 down to move_insn_for_shrink_wrap(). This function moves an insn from one BB to another by copying it and deleting the old one. Unfortunately this does the LABEL_NUSES count on labels referenced because deleting the old instruction decrements the count and nothing in this function is incrementing the count. It just happens that on rs6000 with -m64, force_const_mem() gets called on the address and that sets LABEL_PRESERVE_P on the label which prevents it from being deleted. For whatever reason this doesn't happen in a -m32 compilation, and the label and it's associated jump table data are deleted. This later causes the ICE when the dwarf code tries to look at the label. Segher and I came up with 3 possible solutions to this: 1) Don't let move_insn_for_shrink_wrap try to move insns with label_ref in them. 2) Call mark_jump_label() on the copied instruction to fix up the ref counts. 3) Make the function actually move the insn instead of copying/deleting it. It seemed like option 2 was the best thing for stage 4 as it is not inhibiting anything and is just doing a fixup of the ref count. OK for trunk after regtesting on ppc64be (32/64) and x86_64? Thanks! Aaron 2019-02-13 Aaron Sawdey * shrink-wrap.c (move_insn_for_shrink_wrap): Fix LABEL_NUSES counts on copied instruction. Index: gcc/shrink-wrap.c =================================================================== --- gcc/shrink-wrap.c (revision 268783) +++ gcc/shrink-wrap.c (working copy) @@ -414,7 +414,12 @@ dead_debug_insert_temp (debug, DF_REF_REGNO (def), insn, DEBUG_TEMP_BEFORE_WITH_VALUE); - emit_insn_after (PATTERN (insn), bb_note (bb)); + rtx_insn *insn_copy = emit_insn_after (PATTERN (insn), bb_note (bb)); + /* Update the LABEL_NUSES count on any referenced labels. The ideal + solution here would be to actually move the instruction instead + of copying/deleting it as this loses some notations on the + insn. */ + mark_jump_label (PATTERN (insn), insn_copy, 0); delete_insn (insn); return true; }