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). OK. 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 could mean: v0, v1, ..., v4 for the virtual regnos and, for pseudos that aren't virtual regnos: p0, p1, ... or 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) (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
