From patchwork Wed Sep 13 10:32:24 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 813321 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-462017-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="UfDMZaPJ"; 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 3xsdKC3S1gz9sBW for ; Wed, 13 Sep 2017 20:32:43 +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:date :from:to:cc:subject:message-id:reply-to:mime-version :content-type; q=dns; s=default; b=k7vMqdg4fSFjEB2MffxTEkkIv0hoe C+gr1HL9u5Q9jny6BsWGw+JrAeTtyGhjwenjAJZMOdfEltNTcFSbllGyoj7HjBCl YIrObxmg6Ft6IdLGWhiUKLGrQzBY7Q4jQyJh1ZlAT6moTFuSQWvgE2wcEwSUpvlq kYhRFan23359ko= 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:date :from:to:cc:subject:message-id:reply-to:mime-version :content-type; s=default; bh=emcnNPYkQRHPDNQdjNn/YiPWSD8=; b=UfD MZaPJ+WkRIjwvw+iW8SjjuWR6pq26nZy6UYR8CH01UcoMc0ygwCDBLrBi1Ry+AKc yLRT9sUbOqkLjWVzca3FFHwwiky973sPnacPSMToqf9Boczc/94xNIVBFx3mLn/J TShbl/hI3p/rUkhkVoFu0tXmdLR/1Ec7d+tsQq+I= Received: (qmail 78738 invoked by alias); 13 Sep 2017 10:32:35 -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 78155 invoked by uid 89); 13 Sep 2017 10:32:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-11.9 required=5.0 tests=BAYES_00, GIT_PATCH_2, GIT_PATCH_3, RP_MATCHES_RCVD, SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= 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, 13 Sep 2017 10:32:34 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id ADC38C04B94B; Wed, 13 Sep 2017 10:32:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com ADC38C04B94B Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=jakub@redhat.com Received: from tucnak.zalov.cz (ovpn-116-33.ams2.redhat.com [10.36.116.33]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4FEA966FFB; Wed, 13 Sep 2017 10:32:32 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id v8DAWR9E018658; Wed, 13 Sep 2017 12:32:28 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id v8DAWOG7018657; Wed, 13 Sep 2017 12:32:24 +0200 Date: Wed, 13 Sep 2017 12:32:24 +0200 From: Jakub Jelinek To: Richard Biener , Jeff Law , Uros Bizjak Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] Better fix for the x86_64 -mcmodel=large ICEs (PR target/82145) Message-ID: <20170913103224.GV1701@tucnak> Reply-To: Jakub Jelinek MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.7.1 (2016-10-04) X-IsSubscribed: yes Hi! The testcase below (and others) still ICEs with my PR81766 fix. If there is a cfg cleanup in between ix86_init_pic_reg (during RA) and postreload, the label which my fix moved to the right spot is turned into NOTE_INSN_DELETED_LABEL note and moved back where it originally used to be emitted. The bug is actually in generic code. cselib.c has code to handle LABEL_REF properly during hashing, by not hashing the instructions/notes that are operand thereof, but just the label number. Postreload though calls cselib_lookup directly on the operands of an instruction, and it is very common in many backends to have (label_ref (match_operand ...)) in many patterns, and thus cselib doesn't use the LABEL_REF handling in that case. To avoid crashing postreload.c has: /* cselib blows up on CODE_LABELs. Trying to fix that doesn't seem right, so avoid the problem here. Likewise if we have a constant and the insn pattern doesn't tell us the mode we need. */ if (LABEL_P (recog_data.operand[i]) || (CONSTANT_P (recog_data.operand[i]) && recog_data.operand_mode[i] == VOIDmode)) continue; - we won't look up anything useful for those operands anyway. The problem is that a valid LABEL_REF operand doesn't have to be only a CODE_LABEL, it can be a NOTE with NOTE_INSN_DELETED_LABEL if all we need is the label's address and nothing else. So, the following patch handles NOTE_INSN_DELETED_LABEL like CODE_LABEL in postreload.c. Once that is done, my earlier PR81766 fix can be effectively reverted and instead the CODE_LABEL can be immediately turned into NOTE_INSN_DELETED_LABEL, something that a cfgcleanup would do. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2017-09-13 Jakub Jelinek PR target/82145 * postreload.c (reload_cse_simplify_operands): Skip NOTE_INSN_DELETED_LABEL similarly to skipping CODE_LABEL. * config/i386/i386.c (ix86_init_large_pic_reg): Revert 2017-09-01 changes. Turn CODE_LABEL into NOTE_INSN_DELETED_LABEL immediately. (ix86_init_pic_reg): Revert 2017-09-01 changes. * gcc.target/i386/pr82145.c: New test. Jakub --- gcc/config/i386/i386.c.jj 2017-09-08 09:13:59.000000000 +0200 +++ gcc/config/i386/i386.c 2017-09-11 14:48:50.532094255 +0200 @@ -8885,7 +8885,7 @@ ix86_use_pseudo_pic_reg (void) /* Initialize large model PIC register. */ -static rtx_code_label * +static void ix86_init_large_pic_reg (unsigned int tmp_regno) { rtx_code_label *label; @@ -8902,7 +8902,10 @@ ix86_init_large_pic_reg (unsigned int tm emit_insn (gen_set_got_offset_rex64 (tmp_reg, label)); emit_insn (ix86_gen_add3 (pic_offset_table_rtx, pic_offset_table_rtx, tmp_reg)); - return label; + const char *name = LABEL_NAME (label); + PUT_CODE (label, NOTE); + NOTE_KIND (label) = NOTE_INSN_DELETED_LABEL; + NOTE_DELETED_LABEL_NAME (label) = name; } /* Create and initialize PIC register if required. */ @@ -8911,7 +8914,6 @@ ix86_init_pic_reg (void) { edge entry_edge; rtx_insn *seq; - rtx_code_label *label = NULL; if (!ix86_use_pseudo_pic_reg ()) return; @@ -8921,7 +8923,7 @@ ix86_init_pic_reg (void) if (TARGET_64BIT) { if (ix86_cmodel == CM_LARGE_PIC) - label = ix86_init_large_pic_reg (R11_REG); + ix86_init_large_pic_reg (R11_REG); else emit_insn (gen_set_got_rex64 (pic_offset_table_rtx)); } @@ -8945,22 +8947,6 @@ ix86_init_pic_reg (void) entry_edge = single_succ_edge (ENTRY_BLOCK_PTR_FOR_FN (cfun)); insert_insn_on_edge (seq, entry_edge); commit_one_edge_insertion (entry_edge); - - if (label) - { - basic_block bb = BLOCK_FOR_INSN (label); - rtx_insn *bb_note = PREV_INSN (label); - /* If the note preceding the label starts a basic block, and the - label is a member of the same basic block, interchange the two. */ - if (bb_note != NULL_RTX - && NOTE_INSN_BASIC_BLOCK_P (bb_note) - && bb != NULL - && bb == BLOCK_FOR_INSN (bb_note)) - { - reorder_insns_nobb (bb_note, bb_note, label); - BB_HEAD (bb) = label; - } - } } /* Initialize a variable CUM of type CUMULATIVE_ARGS --- gcc/postreload.c.jj 2017-09-08 09:13:54.000000000 +0200 +++ gcc/postreload.c 2017-09-11 14:49:04.977945563 +0200 @@ -409,9 +409,12 @@ reload_cse_simplify_operands (rtx_insn * CLEAR_HARD_REG_SET (equiv_regs[i]); /* cselib blows up on CODE_LABELs. Trying to fix that doesn't seem - right, so avoid the problem here. Likewise if we have a constant - and the insn pattern doesn't tell us the mode we need. */ + right, so avoid the problem here. Similarly NOTE_INSN_DELETED_LABEL. + Likewise if we have a constant and the insn pattern doesn't tell us + the mode we need. */ if (LABEL_P (recog_data.operand[i]) + || (NOTE_P (recog_data.operand[i]) + && NOTE_KIND (recog_data.operand[i]) == NOTE_INSN_DELETED_LABEL) || (CONSTANT_P (recog_data.operand[i]) && recog_data.operand_mode[i] == VOIDmode)) continue; --- gcc/testsuite/gcc.target/i386/pr82145.c.jj 2017-09-11 14:46:08.612760951 +0200 +++ gcc/testsuite/gcc.target/i386/pr82145.c 2017-09-11 14:47:22.090004622 +0200 @@ -0,0 +1,12 @@ +/* PR target/82145 */ +/* { dg-do compile { target { pie && lp64 } } } */ +/* { dg-options "-O2 -fpie -mcmodel=large -march=haswell" } */ + +int l; + +int +main () +{ + l++; + return 0; +}