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).

When dumping regnos, would you want another distinction between
virtuals and non-virtuals in the dump?  For example, given that
could mean:

  v0, v1, ..., v4  for the virtual regnos

and, for pseudos that aren't virtual regnos:
  p0, p1, ...
  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:

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

Reply via email to