From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 104767 invoked by alias); 20 Sep 2016 19:12:34 -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 104752 invoked by uid 89); 20 Sep 2016 19:12:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.0 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=humans, reader 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 19:12:32 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (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 50EF2C05490D for ; Tue, 20 Sep 2016 19:12:31 +0000 (UTC) Received: from vpn-234-88.phx2.redhat.com (vpn-234-88.phx2.redhat.com [10.3.234.88]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8KJCUEX005141; Tue, 20 Sep 2016 15:12:30 -0400 Message-ID: <1474398749.23088.48.camel@redhat.com> Subject: Re: 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 19:35:00 -0000 In-Reply-To: <68259aad-5d10-b440-29e9-641e431219a9@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> <1474381937.23088.35.camel@redhat.com> <4e808d04-c69e-8fd1-2b65-da93f0643b52@redhat.com> <68259aad-5d10-b440-29e9-641e431219a9@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/msg01357.txt.bz2 On Tue, 2016-09-20 at 09:20 -0600, Jeff Law wrote: > On 09/20/2016 08:34 AM, Bernd Schmidt wrote: > > On 09/20/2016 04:32 PM, David Malcolm wrote: > > > > > > 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. > > > > Renumbering is not helpful because it interferes with the view you > > have > > in the debugger. So, IMO just a prefix, and maybe > Yea, I guess it does since we want the numbers in the dump to be the > same that we used to access the arrays. So prefixing in the dump > with > adjustment of the number in the reader. To check I understand: am I right in thinking you want: (A) the numbers in the dump to be unmodified when dumping, so that we can easily look up values in arrays without confusion, and (B) regnums in the dump gain a 'p' prefix for values >= FIRST_PSEUDO_REGISTER, so that humans and parsers can easily see when the regs are pseudos, and that (C) the parser will detect if a 'p'-prefixed regno actually has the same number as a hard reg (which can happen e.g. when a .md file changes, or when sharing .rtl dumps between targets), and remap the values on load accordingly ? (in which case we do need the regno_remapper class, or something like it) > > > > > (reg/f:DI v1 virtual-stack-vars) > > > > this. > Doesn't the same apply to the number of virtual stack regs? Those > are > in the same array as pseudos. So ISTM we prefix in the dump, but do > adjustment of the number in the reader? Presumably we could use "v" rather than "p" as the prefix for the first 5 pseudos (up to LAST_VIRTUAL_REGISTER), doing any adjustment at load time, rather than at dump time. So the above example would look like: (reg/f:DI v82 virtual-stack-vars) i.e. the 82 for x86_64's virtual-stack-vars would be prefixed with a 'v', and the loader would adjust it to be the current target's value for VIRTUAL_STACK_VARS_REGNUM. Do you like the idea of prefixing regnums of hardregs with 'h'? (so that all regnos get a one-char prefix) e.g. (reg/i:SI h0 ax) (reg/i:SF h21 xmm0) Dave