From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 44090 invoked by alias); 16 Sep 2016 21:27:22 -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 44077 invoked by uid 89); 16 Sep 2016 21:27:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1947, Best, 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; Fri, 16 Sep 2016 21:27:20 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (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 3E075A2028 for ; Fri, 16 Sep 2016 21:27:19 +0000 (UTC) Received: from vpn-233-121.phx2.redhat.com (vpn-233-121.phx2.redhat.com [10.3.233.121]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8GLRIht010942; Fri, 16 Sep 2016 17:27:18 -0400 Message-ID: <1474061238.6782.99.camel@redhat.com> Subject: Re: [PATCH 0/9] RFC: selftests based on RTL dumps From: David Malcolm To: Jeff Law , Bernd Schmidt , gcc-patches@gcc.gnu.org Date: Fri, 16 Sep 2016 21:28:00 -0000 In-Reply-To: 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> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-09/txt/msg01100.txt.bz2 On Fri, 2016-09-16 at 14:05 -0600, Jeff Law wrote: > On 09/13/2016 05:15 AM, Bernd Schmidt wrote: > > > > > > Note that the loader now resets INSN_CODE to -1, regardless of > > > the > > > actual code passed in, to force re-recognition, and to isolate > > > the > > > dumps somewhat from changes to the .md files. So although the > > > above > > > says insn 641 and 642 (for some snapshot of the aarch64 md file), > > > it > > > gets reset to -1. > > > > Best to find out a way to avoid including it in the strings then, > > to > > avoid confusion. > 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. > 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. 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?)