From patchwork Fri Nov 6 10:48:32 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bernd Schmidt X-Patchwork-Id: 540916 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 9B0F814030D for ; Fri, 6 Nov 2015 21:49:05 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=HsoyjLQc; 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 :subject:to:references:cc:from:message-id:date:mime-version :in-reply-to:content-type; q=dns; s=default; b=i8YBHsz2bdv8NlVbB tnQw1IEMwXF2VDojrDPief7W1IGOcCXwpLC/H/AWd7FWHQjtE9lhF4JC4o4bBZtU ysCUh2sXh2FK8miSkGzP0kNyVv31ZOMPV2U0VL4a0Ex0jobDAfzZ6Tx8tdrirDzn u1uYIN8bDrW9aNfSrUjW6GG+h8= 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 :subject:to:references:cc:from:message-id:date:mime-version :in-reply-to:content-type; s=default; bh=VbAYXddkYX8Stqdn+fBU6yV 0Z5w=; b=HsoyjLQcOqFepKgiZPjxu5yF8aiVpayqes6bZ9ZBWPXC9KQ+ghiyBWI zmK63BXMOk6YJrXADA3Ooqw/f5AmjAs3Vovyd8SrcLeVlOw+fluBfa6SIjOZLfEb MzCvQlEREnDc6DhPxRem01uuGt7V4PYj3K/GUUTla4ddfGFbn29A= Received: (qmail 47115 invoked by alias); 6 Nov 2015 10:48:51 -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 46151 invoked by uid 89); 6 Nov 2015 10:48:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.6 required=5.0 tests=AWL, BAYES_05, KAM_ASCII_DIVIDERS, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_NONE, T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mailout02.t-online.de Received: from mailout02.t-online.de (HELO mailout02.t-online.de) (194.25.134.17) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 06 Nov 2015 10:48:43 +0000 Received: from fwd41.aul.t-online.de (fwd41.aul.t-online.de [172.20.27.139]) by mailout02.t-online.de (Postfix) with SMTP id 15E88527231; Fri, 6 Nov 2015 11:48:39 +0100 (CET) Received: from [192.168.2.105] (VmnhjwZEQhr7Z-SG5vOtsXRjnJNybcaCtK2vRWMtllfA+oyw-j7cTIJynTkenLIgZG@[84.167.116.215]) by fwd41.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1ZueZS-4UROPA0; Fri, 6 Nov 2015 11:48:38 +0100 Subject: Re: [patch] fix regrename pass to ensure renamings produce valid insns To: Sandra Loosemore , GCC Patches References: <5581AA41.7010201@codesourcery.com> Cc: Chung-Lin Tang From: Bernd Schmidt Message-ID: <563C8580.8060805@t-online.de> Date: Fri, 6 Nov 2015 11:48:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5581AA41.7010201@codesourcery.com> X-IsSubscribed: yes On 06/17/2015 07:11 PM, Sandra Loosemore wrote: > Index: gcc/regrename.c > =================================================================== > --- gcc/regrename.c (revision 224532) > +++ gcc/regrename.c (working copy) > @@ -942,19 +942,22 @@ regrename_do_replace (struct du_head *he > int reg_ptr = REG_POINTER (*chain->loc); > > if (DEBUG_INSN_P (chain->insn) && REGNO (*chain->loc) != base_regno) > - INSN_VAR_LOCATION_LOC (chain->insn) = gen_rtx_UNKNOWN_VAR_LOC (); > + validate_change (chain->insn, &(INSN_VAR_LOCATION_LOC (chain->insn)), > + gen_rtx_UNKNOWN_VAR_LOC (), true); > else > { > - *chain->loc = gen_raw_REG (GET_MODE (*chain->loc), reg); > + validate_change (chain->insn, chain->loc, > + gen_raw_REG (GET_MODE (*chain->loc), reg), true); > if (regno >= FIRST_PSEUDO_REGISTER) > ORIGINAL_REGNO (*chain->loc) = regno; > REG_ATTRS (*chain->loc) = attr; With a patch I'm working on that uses the renamer more often, I found that this is causing compare-debug failures. Validating changes to debug_insns (the INSN_VAR_LOCATION_LOC in particular) can apparently fail. The following fix was bootstrapped and tested with -frename-registers enabled at -O1 on x86_64-linux. Ok? Bernd * regrename.c (regrename_do_replace): Do not validate changes to debug insns. Index: gcc/regrename.c =================================================================== --- gcc/regrename.c (revision 229049) +++ gcc/regrename.c (working copy) @@ -946,10 +951,7 @@ regrename_do_replace (struct du_head *he struct reg_attrs *attr = REG_ATTRS (*chain->loc); int reg_ptr = REG_POINTER (*chain->loc); - if (DEBUG_INSN_P (chain->insn) && REGNO (*chain->loc) != base_regno) - validate_change (chain->insn, &(INSN_VAR_LOCATION_LOC (chain->insn)), - gen_rtx_UNKNOWN_VAR_LOC (), true); - else + if (!DEBUG_INSN_P (chain->insn)) { validate_change (chain->insn, chain->loc, gen_raw_REG (GET_MODE (*chain->loc), reg), true); @@ -963,6 +965,16 @@ regrename_do_replace (struct du_head *he if (!apply_change_group ()) return false; + for (chain = head->first; chain; chain = chain->next_use) + if (DEBUG_INSN_P (chain->insn)) + { + if (REGNO (*chain->loc) != base_regno) + INSN_VAR_LOCATION_LOC (chain->insn) = gen_rtx_UNKNOWN_VAR_LOC (); + else + *chain->loc = gen_raw_REG (GET_MODE (*chain->loc), reg); + df_insn_rescan (chain->insn); + } + mode = GET_MODE (*head->first->loc); head->regno = reg; head->nregs = hard_regno_nregs[reg][mode];