From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 41408 invoked by alias); 20 Sep 2016 14:32:27 -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 41391 invoked by uid 89); 20 Sep 2016 14:32:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.0 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=cater, reader, our 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, 20 Sep 2016 14:32:20 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (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 EC1777EA85 for ; Tue, 20 Sep 2016 14:32:18 +0000 (UTC) Received: from vpn-234-88.phx2.redhat.com (vpn-234-88.phx2.redhat.com [10.3.234.88]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8KEWH9u001472; Tue, 20 Sep 2016 10:32:18 -0400 Message-ID: <1474381937.23088.35.camel@redhat.com> Subject: Register numbers in RTL dumps (was Re: [PATCH 0/9] RFC: selftests based on RTL dumps) From: David Malcolm To: Jeff Law , Bernd Schmidt , gcc-patches@gcc.gnu.org Date: Tue, 20 Sep 2016 14:34:00 -0000 In-Reply-To: <58dd738d-a5fc-a3ae-3123-2ddb2c7c525a@redhat.com> References: <1473381053-18817-1-git-send-email-dmalcolm@redhat.com> <319e562e-7b25-9e9d-eced-1ea4b7c2f109@redhat.com> <1473706655.6782.36.camel@redhat.com> <9b71a775-cf7c-1b14-1ce4-b146523663a3@redhat.com> <1474061238.6782.99.camel@redhat.com> <58dd738d-a5fc-a3ae-3123-2ddb2c7c525a@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/msg01305.txt.bz2 On Mon, 2016-09-19 at 11:35 -0600, Jeff Law wrote: > On 09/16/2016 03:27 PM, David Malcolm wrote: > > > We should also twiddle how we represent registers in the dumps. > > > Identifying hard regs by name (so we can map back to a hard reg > > > if > > > the > > > hard regs change), identifying pseudos by number that isn't > > > affected > > > if > > > the hard register set changes ie, p0, p1, p2, p3 where the number > > > is > > > REGNO (x) - FIRST_PSEUDO_REGISTER. identifying the virtual > > > registers, > > > etc. > > > > Good idea. > > > > I don't know if you saw this yet, but the patch has logic from > > renumbering pseudos on load (see class regno_remapper), but dumping > > them as p0, p1 etc and reloading them as such seems much easier for > > everyone. > And just an FYI, I think we should do this unconditionally in our > dumps. To summarize so far: you want every pseudo to have its regno dumped with a 'p' prefix, and renumber them on dump (and then on load). OK. When dumping regnos, would you want another distinction between virtuals and non-virtuals in the dump? For example, given that LAST_VIRTUAL_POINTER_REGISTER is ((FIRST_VIRTUAL_REGISTER) + 4), this could mean: v0, v1, ..., v4 for the virtual regnos and, for pseudos that aren't virtual regnos: p0, p1, ... or p5, p6, ... depending on whether we want to start numbering the pseudos at p0 for LAST_VIRTUAL_REGISTER + 1, or whether we regard v0 as the first pseduo, and hence p5 is the first non-virtual pseudo. FWIW I think starting at p5 is the better approach, given that: #define FIRST_VIRTUAL_REGISTER (FIRST_PSEUDO_REGISTER) Either way, this would give things like: (reg/f:DI v1 virtual-stack-vars) (reg:DI p78) In a similar vein, how about adding a "h" prefix for the hard regnos? That way every regno would have a one-char prefix telling you what kind of reg it is (and you can directly see whether or not you need to offset the number by FIRST_PSEUDO_REGISTER to get at the "real" regno). This would give things (for x86_64) like: (reg/i:SI h0 ax) (reg/i:SF h21 xmm0) > > > > > The key being rather than put a ton of smarts/hacks in a reader, > > > we > > > should work to have the RTL writer give us something more useful. > > > That > > > may mean simple changes to the output, or some conditional > > > changes > > > (like > > > not emitting the INSN_CODE or its name). > > > > That would make the reader a lot less grim; it has a lot of warts > > for > > dealing with all the special cases in the current output format. > That's the idea. > > > > But maybe it is useful to be able to deal with the current output > > format. For example, I was able to look at PR 71779 and find some > > fragmentary RTL dumps there (comment #2) and use them. I *did* > > need to > > edit them a little, so maybe it's OK to require a little editing > > (especially with older dumps... to what extent has the format > > changed > > over the years?) > It's changed, but not in radical ways. > > I think the case we want to cater to is dumping something from the > current compiler rather than picking up some crusty RTL and creating > a > testcase from that. By "current" I explicitly want the ability to > refine the output to make the reader easier to implement. > > Jeff