On Fri, 2016-09-16 at 14:05 -0600, Jeff Law wrote: > On 09/13/2016 05:15 AM, Bernd Schmidt wrote: > > > > > > Note that the loader now resets INSN_CODE to -1, regardless of > > > the > > > actual code passed in, to force re-recognition, and to isolate > > > the > > > dumps somewhat from changes to the .md files. So although the > > > above > > > says insn 641 and 642 (for some snapshot of the aarch64 md file), > > > it > > > gets reset to -1. > > > > Best to find out a way to avoid including it in the strings then, > > to > > avoid confusion. > 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. > 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. 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?)
