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
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
LAST_VIRTUAL_POINTER_REGISTER is ((FIRST_VIRTUAL_REGISTER) + 4), this
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:
#define FIRST_VIRTUAL_REGISTER (FIRST_PSEUDO_REGISTER)
Either way, this would give things like:
(reg/f:DI v1 virtual-stack-vars)
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
> testcase from that. By "current" I explicitly want the ability to
> refine the output to make the reader easier to implement.