Re: Register numbers in RTL dumps (was Re: [PATCH 0/9] RFC: selftests based on RTL dumps)
On Tue, 2016-09-20 at 09:20 -0600, Jeff Law wrote: > On 09/20/2016 08:34 AM, Bernd Schmidt wrote: > > On 09/20/2016 04:32 PM, David Malcolm wrote: > > > > > > 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. > > > > Renumbering is not helpful because it interferes with the view you > > have > > in the debugger. So, IMO just a prefix, and maybe > Yea, I guess it does since we want the numbers in the dump to be the > same that we used to access the arrays. So prefixing in the dump > with > adjustment of the number in the reader. To check I understand: am I right in thinking you want: (A) the numbers in the dump to be unmodified when dumping, so that we can easily look up values in arrays without confusion, and (B) regnums in the dump gain a 'p' prefix for values >= FIRST_PSEUDO_REGISTER, so that humans and parsers can easily see when the regs are pseudos, and that (C) the parser will detect if a 'p'-prefixed regno actually has the same number as a hard reg (which can happen e.g. when a .md file changes, or when sharing .rtl dumps between targets), and remap the values on load accordingly ? (in which case we do need the regno_remapper class, or something like it) > > > > > (reg/f:DI v1 virtual-stack-vars) > > > > this. > Doesn't the same apply to the number of virtual stack regs? Those > are > in the same array as pseudos. So ISTM we prefix in the dump, but do > adjustment of the number in the reader? Presumably we could use "v" rather than "p" as the prefix for the first 5 pseudos (up to LAST_VIRTUAL_REGISTER), doing any adjustment at load time, rather than at dump time. So the above example would look like: (reg/f:DI v82 virtual-stack-vars) i.e. the 82 for x86_64's virtual-stack-vars would be prefixed with a 'v', and the loader would adjust it to be the current target's value for VIRTUAL_STACK_VARS_REGNUM. Do you like the idea of prefixing regnums of hardregs with 'h'? (so that all regnos get a one-char prefix) e.g. (reg/i:SI h0 ax) (reg/i:SF h21 xmm0) Dave
Re: Register numbers in RTL dumps (was Re: [PATCH 0/9] RFC: selftests based on RTL dumps)
On 09/20/2016 05:20 PM, Jeff Law wrote: On 09/20/2016 08:34 AM, Bernd Schmidt wrote: (reg/f:DI v1 virtual-stack-vars) this. Doesn't the same apply to the number of virtual stack regs? Those are in the same array as pseudos. So ISTM we prefix in the dump, but do adjustment of the number in the reader? I meant the virtual-stack-vars name. But maybe we're already doing that, I can't remember. Bernd
Re: Register numbers in RTL dumps (was Re: [PATCH 0/9] RFC: selftests based on RTL dumps)
On 09/20/2016 08:34 AM, Bernd Schmidt wrote: On 09/20/2016 04:32 PM, David Malcolm wrote: 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. Renumbering is not helpful because it interferes with the view you have in the debugger. So, IMO just a prefix, and maybe Yea, I guess it does since we want the numbers in the dump to be the same that we used to access the arrays. So prefixing in the dump with adjustment of the number in the reader. (reg/f:DI v1 virtual-stack-vars) this. Doesn't the same apply to the number of virtual stack regs? Those are in the same array as pseudos. So ISTM we prefix in the dump, but do adjustment of the number in the reader? jeff
Re: Register numbers in RTL dumps (was Re: [PATCH 0/9] RFC: selftests based on RTL dumps)
On 09/20/2016 04:32 PM, David Malcolm wrote: 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. Renumbering is not helpful because it interferes with the view you have in the debugger. So, IMO just a prefix, and maybe (reg/f:DI v1 virtual-stack-vars) this. Bernd
Register numbers in RTL dumps (was Re: [PATCH 0/9] RFC: selftests based on RTL dumps)
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
