On 09/21/2016 01:01 PM, David Malcolm wrote:
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)
(Replying to myself, in the hope of better demonstrating the idea)
The following patch implements this idea for RTL dumps, so that all REGNO
values in dumps get a one character prefix: 'h' for hard registers, 'v'
for virtual registers, and 'p' for non-virtual pseudos (making it easier
for both humans and parsers to grok the meaning of a REGNO).
I think you nailed it. h, v & p prefixing for each of the register
types, but leaving the actual register number as-is in the dump file.
Successfully bootstrapped on x86_64-pc-linux-gnu.
There are various regression test failures involving scan-rtl-dump
due to regexes not matching e.g.
PASS -> FAIL : gcc.target/i386/pr20020-1.c scan-rtl-dump expand "\\(set \\(reg/i:TI
0 ax\\)"
PASS -> FAIL : gcc.target/i386/pr20020-1.c scan-rtl-dump expand "\\(set \\(reg:TI [0-9]*
\\[ <retval> \\]\\)"
If the approach is OK, I can do an updated patch that also fixes up the
relevant tests (adding the appropriate prefixes); this would touch
multiple targets.
Yea. This obviously highlights some of the long term issues with making
changes into the dump format. As I said in our meeting yesterday, I do
understand the desire to nail down the format :-) But I also want to
use the opportunity we have to make the dumps easier for your work to
read & interpret.
jeff