This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] print-rtx.c: add 'h', v' and 'p' prefixes to regnos


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]