public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <law@redhat.com>
To: Bernd Schmidt <bschmidt@redhat.com>,
	David Malcolm <dmalcolm@redhat.com>,
	       gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] print-rtx.c: add 'h', v' and 'p' prefixes to regnos
Date: Wed, 28 Sep 2016 17:11:00 -0000	[thread overview]
Message-ID: <ff731197-e1d8-b2c7-8a43-ab550dc4662f@redhat.com> (raw)
In-Reply-To: <df3db96e-d087-4af6-f36a-fe133761a237@redhat.com>

On 09/28/2016 10:30 AM, Bernd Schmidt wrote:
> On 09/28/2016 06:23 PM, Jeff Law wrote:
>
>>>>   (reg/i:SI h0 ax)
>>>>   (reg/i:SF h21 xmm0)
>>>
>>> (Replying to myself, in the hope of better demonstrating the idea)
>>>
>>> The following patch implements this idea for RTL dumps, so that all
>>> REGNO
>>> values in dumps get a one character prefix: 'h' for hard registers, 'v'
>>> for virtual registers, and 'p' for non-virtual pseudos (making it easier
>>> for both humans and parsers to grok the meaning of a REGNO).
>> I think you nailed it.  h, v & p prefixing for each of the register
>> types, but leaving the actual register number as-is in the dump file.
>>
> I'm actually no longer quite so sure this buys us much: a port might
> have an actual register named "h0", leading to confusion. Virtual and
> hard registers also already have their real name printed after the number.
>
> 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?

The case I'm worried about is the register meanings in a testsuite dump 
file changing over time if/when new hard registers are added to the port 
or we introduce new virtual registers.

FOr hard regs and virtuals we can probably map backwards using their 
names.  So given a register in a dump, if we can't reverse map it back 
to a hard reg or a virtual, then we assume its a pseudo?

jeff

  reply	other threads:[~2016-09-28 16:36 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-09  0:01 [PATCH 0/9] RFC: selftests based on RTL dumps David Malcolm
2016-09-09  0:01 ` [PATCH 9/9] cse.c selftests David Malcolm
2016-09-16 20:34   ` Jeff Law
2016-09-16 21:28     ` David Malcolm
2016-09-19 17:37       ` Jeff Law
2016-09-22  3:23         ` [PATCH] Introduce selftest::locate_file David Malcolm
2016-09-28 16:33           ` Jeff Law
2016-09-09  0:01 ` [PATCH 4/9] Expose forcibly_ggc_collect and run it after all selftests David Malcolm
2016-09-16 20:30   ` Jeff Law
2016-09-09  0:01 ` [PATCH 6/9] df selftests David Malcolm
2016-09-16 20:40   ` Jeff Law
2016-09-16 21:34     ` David Malcolm
2016-09-09  0:01 ` [PATCH 1/9] Introduce class rtx_reader David Malcolm
2016-09-16 22:15   ` Jeff Law
2016-09-21 17:22     ` [PATCH, v2] " David Malcolm
2016-09-21 20:44       ` Richard Sandiford
2016-09-09  0:01 ` [PATCH 8/9] final.c selftests David Malcolm
2016-09-16 21:12   ` Jeff Law
2016-09-16 21:41     ` David Malcolm
2016-09-19 21:38       ` Jeff Law
2016-09-09  0:01 ` [PATCH 7/9] combine.c selftests David Malcolm
2016-09-16 20:45   ` Jeff Law
2016-09-16 21:39     ` David Malcolm
2016-09-09  0:01 ` [PATCH 3/9] selftest.h: add temp_override fixture David Malcolm
2016-09-14 22:24   ` Trevor Saunders
2016-09-16 20:37   ` Jeff Law
2016-09-09  0:01 ` [PATCH 2/9] Add selftest::read_file David Malcolm
2016-09-16 21:19   ` Jeff Law
2016-09-09  0:13 ` [PATCH 5/9] Introduce class function_reader David Malcolm
2016-09-16 21:31   ` Jeff Law
2016-09-16 22:04     ` David Malcolm
2016-09-19 21:39       ` Jeff Law
2016-09-12 14:14 ` [PATCH 0/9] RFC: selftests based on RTL dumps Bernd Schmidt
2016-09-12 18:59   ` David Malcolm
2016-09-13 11:35     ` Bernd Schmidt
2016-09-14 10:33       ` Bernd Schmidt
2016-09-16 20:26       ` Jeff Law
2016-09-16 21:28         ` David Malcolm
2016-09-19 17:50           ` Jeff Law
2016-09-20 14:34             ` Register numbers in RTL dumps (was Re: [PATCH 0/9] RFC: selftests based on RTL dumps) David Malcolm
2016-09-20 14:38               ` Bernd Schmidt
2016-09-20 15:26                 ` Jeff Law
2016-09-20 15:38                   ` Bernd Schmidt
2016-09-20 19:35                   ` David Malcolm
2016-09-21 18:59                     ` [PATCH] print-rtx.c: add 'h', v' and 'p' prefixes to regnos David Malcolm
2016-09-28 16:30                       ` Jeff Law
2016-09-28 16:33                         ` Bernd Schmidt
2016-09-28 17:11                           ` Jeff Law [this message]
2016-09-28 17:19                             ` Bernd Schmidt
2016-09-29 13:00                               ` David Malcolm
2016-09-29 17:32                               ` Jeff Law
2016-09-13 20:39     ` [PATCH 0/9] RFC: selftests based on RTL dumps Jeff Law
2016-09-14  8:44       ` Richard Biener
2016-09-16 20:16         ` Jeff Law
2016-09-16 21:27           ` David Malcolm
2016-09-19 12:21             ` Bernd Schmidt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ff731197-e1d8-b2c7-8a43-ab550dc4662f@redhat.com \
    --to=law@redhat.com \
    --cc=bschmidt@redhat.com \
    --cc=dmalcolm@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).