From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27412 invoked by alias); 29 Sep 2016 12:53:06 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 27395 invoked by uid 89); 29 Sep 2016 12:53:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=resilient, reader, gained, material 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; Thu, 29 Sep 2016 12:53:04 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 14A1B9E606 for ; Thu, 29 Sep 2016 12:53:03 +0000 (UTC) Received: from vpn-234-204.phx2.redhat.com (vpn-234-204.phx2.redhat.com [10.3.234.204]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8TCr2Pj028693; Thu, 29 Sep 2016 08:53:02 -0400 Message-ID: <1475153581.15078.17.camel@redhat.com> Subject: Re: [PATCH] print-rtx.c: add 'h', v' and 'p' prefixes to regnos From: David Malcolm To: Bernd Schmidt , Jeff Law , gcc-patches@gcc.gnu.org Date: Thu, 29 Sep 2016 13:00:00 -0000 In-Reply-To: <8c711824-8d21-1e61-82db-babe9721037c@redhat.com> References: <1474398749.23088.48.camel@redhat.com> <1474484478-55517-1-git-send-email-dmalcolm@redhat.com> <1f79d2db-c542-f1e4-c520-78cf603b277b@redhat.com> <8c711824-8d21-1e61-82db-babe9721037c@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-09/txt/msg02239.txt.bz2 On Wed, 2016-09-28 at 18:49 +0200, Bernd Schmidt wrote: > On 09/28/2016 06:36 PM, Jeff Law wrote: > > > A "p" prefix for pseudos might still be a good idea, but there's > > > still > > > the issue of a real "p0" register name causing confusion. > > So how do you think we should deal with distinguishing between the > > different registers that may appear in a dump file? > > I think the main problem we were trying to solve is making sure we > can > make future-proof dumps. So that would argue for allowing h0, v0, p0 > syntax in the reader, but not printing them out that way by default. > > Also, if we don't already, allow hard regs to be specified by name in > the reader, and maybe even require it for virtuals. Yes: the problems I'm trying to solve here are: (a) making dumps more resilient against changing .md files, and (b) where possible, allowing target-independent dump fragments where everything is a pseudo The issue I ran into was parsing the "r" format code, for a regno, where print_rtx can print various things after the actual number. My hope with the prefix patch was to give the parser more of a hint as to the category of reg (and to perhaps make dumps easier for humans to read). But it looks like the "r" format code is only ever used by REG, which means there's always a closing parenthesis at the end of the material emitted for the "r" format code. So given that I *think* that the parser already has all it needs, and that the patch is redundant. So my plan for the reader is: - read the number emitted by "r" - see if there's a name after the number. If there is, assume a hard or virtual reg, and try to parse the name: - if the name is recognized, use the target's current number for that name (future-proofing virtuals against .md changes) - if the name is not recognized, issue a fatal error (it's probably a typo, or maybe a backport from a future version of gcc, or a target incompatibility) - if there's no name, assume it's a pseudo. Remap all pseudos in a postprocessing phase to ensure that they *are* pseudos (even if the .md has gained some hard regs in the meantime), leaving the numbering untouched if possible (the common case). ...and to drop the regno-prefixing idea from this patch. Hopefully this sounds sane. (I'm also working on a function-dumping patch, which will cover CFG information and various "crtl" information and other state that can't be reconstructed and hence ought to be in the dump). Dave