RTL frontend input format again (was Re: [PATCH 15/16] RTL frontend (rtl1), on top of dump reader)

David Malcolm dmalcolm@redhat.com
Fri Oct 7 18:08:00 GMT 2016


On Fri, 2016-10-07 at 15:58 +0200, Bernd Schmidt wrote:
> On 10/07/2016 03:26 PM, David Malcolm wrote:
> > 
> > We could simply print the INSN_UID for CODE_LABELs; something like
> > this
> > (see the "(code_label 16" below):
> 
> I think that should work.

OK: we'll keep the INSN_UID for CODE_LABELs when suppressing it for
others.

Should we drop the "[1 uses]" in the code_label? i.e. should it look
like this:

    (code_label 16 [1 uses])

or this:

    (code_label 16)

> > You appear to have trimmed the idea of enclosing the insns with
> > (basic-block) directives without commenting on it.  Did you like
> > this
> > idea?
> 
> Sorry - I appear to have completely missed it.
> 
> > It would make the above look like:
> > 
> >   (basic-block 2
> >     ;; insns snipped
> >     (jump_insn (set (pc)
> >             (if_then_else (ge (reg:CCGC 17 flags)
> >                     (const_int 0 [0]))
> >                 (label_ref 16)
> >                 (pc))) "test.c":3
> >    -> 16)
> >   ) ;; basic-block 2
> >   (basic-block 4
> >     (note [bb 4] NOTE_INSN_BASIC_BLOCK)
> >     ;; insns snipped
> >     (jump_insn (set (pc) (label_ref 20)) "test.c":4
> >      -> 20)
> >   ) ;; basic-block 4
> >   (barrier)
> >   (basic-block 5
> >     (code_label 16 [1 uses])
> >     (note [bb 5] NOTE_INSN_BASIC_BLOCK)
> >     ;; etc
> >   ) ;; basic-block 5
> > 
> > Note how the above format expresses clearly that:
> > * the (barrier) is part of the insn chain, but not in a basic
> > block, and
> > * some insns can happen in a basic block
> 
> That looks really nice IMO. Except maybe drop the "-> 16" bit for the
> jump_insn (that's the JUMP_LABEL, isn't it?)

It is the JUMP_LABEL.  This can be an INSN_UID, but it can also be
"return" or "simple_return"; presumably we do want to print JUMP_LABEL
somehow, though maybe it's always possible to reconstruct it:

  (jump_insn (simple_return) "test.c":15
   -> simple_return)

> > Taking this idea further: if we have (basic-block) directives
> > integrated into the insn-chain like this, we could express the CFG
> > by
> > adding (edge) directives. Here's a suggestion for doing it with
> > (edge-from) and (edge-to) directives, expressing the predecessor
> > and
> > successor edges in the CFG, along with :
> 
> That also looks reasonable. Probably a small but maybe not a huge 
> improvement over the other syntax. Having both from and to edges
> seems 
> redundant but might help readability. The reader should check 
> consistency in that case.

Would you prefer if it just showed out-edges?  If so, should the
directive be just "(edge" rather than "(edge-to"?

Did you like the stringified flags? e.g.

    (edge-to 4 (flags "FALLTHRU"))

presumably with | separators within the string e.g.:

    (edge-to 4 (flags "ABNORMAL | EH"))

> > Should we spell "0" and "1" as "entry" and "exit" when
> > parsing/dumping
> > basic block indices? e.g.:
> > 
> >   (basic-block 2
> >     (edge-from entry)
> 
> If that can be done it would be an improvement.

Yes, it ought to be simple to do.

> > > I think maybe you want a separate compact form of insns and notes
> > > (cinsn/cnote maybe), with a flag selecting which gets written out
> > > in
> > > the
> > > dumper. The reader could then read them in like any other rtx
> > > code,
> > > and
> > > there'd be a postprocessing stage to reconstruct the insn chain.
> > 
> > By this separate compact form, do you mean the form we've been
> > discussing above, with no INSN_UID/PREV/NEXT, etc?  Or something
> > else?
> 
> Yes, the form we're discussing, except instead of (insn ...) you'd
> have 
> (cinsn ...), which I assume would make it easier for the reader and
> less 
> ambiguous overall.

By "reader" do you mean humans or computers? (or both?)

> > As for "cinsn", "cnote", how about just "insn" and "note", and
> > having
> > the compactness be expressed at the top of the dump e.g. implicitly
> > by
> > the presence of a "(function" directive.  Could even have a format
> > version specifier in the function directive, to give us some future
> > -proofing e.g.
> >   (function (format 20161007)
> > or somesuch.
> 
> Having it implicit should also be ok - I have no strong preference 
> really. I'm not sure we want versioning - better to have an automatic
> conversion if we ever feel we need to change the format.

OK

> > Do you want to want to try hand-edited a test case, using some of
> > the
> > format ideas we've been discussing?  That might suggest further
> > improvements to the format.
> 
> We'll definitely want to have a look at one or two. Also, we ought to
> try to set up situations we haven't discussed: ADDR_VECs (in light of
> the basic block dumping) and ASMs maybe. I'm probably forgetting
> some.

Example of an ADDR_VEC:
There was one of these in patch 4 of v1 of the patch kit
  https://gcc.gnu.org/ml/gcc-patches/2016-05/msg00355.html
in "rtl.dg/roundtrip/test-switch-after-expand.rtl"; it looks like this:

(jump_table_data 18 17 19 (nil) (addr_vec:DI [
            (label_ref:DI 66)
            (label_ref:DI 20)
            (label_ref:DI 20)
            (label_ref:DI 20)
            (label_ref:DI 20)
            (label_ref:DI 20)
            (label_ref:DI 20)
            (label_ref:DI 20)
            (label_ref:DI 20)
            (label_ref:DI 20)
            (label_ref:DI 20)
            (label_ref:DI 35)
            (label_ref:DI 40)
            (label_ref:DI 46)
            (label_ref:DI 52)
            (label_ref:DI 52)
            (label_ref:DI 52)
            (label_ref:DI 52)
            (label_ref:DI 52)
            (label_ref:DI 52)
            (label_ref:DI 52)
            (label_ref:DI 52)
            (label_ref:DI 52)
            (label_ref:DI 52)
            (label_ref:DI 25)
            (label_ref:DI 30)
        ]))

If we trim the INSN_UIDs and (nil) basic block, it would look like:

(jump_table_data (addr_vec:DI [
            (label_ref:DI 66)
           
 (label_ref:DI 20)
            (label_ref:DI 20)
           
 (label_ref:DI 20)
            (label_ref:DI 20)
           
 (label_ref:DI 20)
            (label_ref:DI 20)
           
 (label_ref:DI 20)
            (label_ref:DI 20)
           
 (label_ref:DI 20)
            (label_ref:DI 20)
           
 (label_ref:DI 35)
            (label_ref:DI 40)
           
 (label_ref:DI 46)
            (label_ref:DI 52)
           
 (label_ref:DI 52)
            (label_ref:DI 52)
           
 (label_ref:DI 52)
            (label_ref:DI 52)
           
 (label_ref:DI 52)
            (label_ref:DI 52)
           
 (label_ref:DI 52)
            (label_ref:DI 52)
           
 (label_ref:DI 52)
            (label_ref:DI 25)
           
 (label_ref:DI 30)
        ]))

which looks reasonable.


Example of an inline asm (for x86_64):

Given e.g.:

uint64_t
get_timestamp (void)
{
  uint64_t msr;
     
  asm volatile ("rdtsc\n\t"    // Returns the time in EDX:EAX.
		"shl $32, %%rdx\n\t"  // Shift the upper bits left.
		"or %%rdx, %0"        // 'Or' in the lower bits.
		: "=a" (msr)
		:
		: "rdx");
  return msr;
}

the dump at "final" currently contains:

(insn 6 2 5 2 (parallel [
            (set (reg:DI 0 ax [orig:89 msr ] [89])
                (asm_operands/v:DI ("rdtsc
        shl $32, %%rdx
        or %%rdx, %0") ("=a") 0 []
                     []
                     [] test-asm.c:8))
            (clobber (reg:DI 1 dx))
            (clobber (reg:CCFP 18 fpsr))
            (clobber (reg:CC 17 flags))
        ]) test-asm.c:8 -1
     (nil))

Editing it by hand to the currently proposed format (omitting insn
UIDs, basic block#s, INSN_CODE and various "(nil)"s) gives:

(insn (parallel [
            (set (reg:DI ax [orig:89 msr ] [89])
                (asm_operands/v:DI ("rdtsc
        shl $32, %%rdx
        or %%rdx, %0") ("=a") 0 []
                     []
                     [] "test-asm.c":8))
            (clobber (reg:DI dx))
            (clobber (reg:CCFP fpsr))
            (clobber (reg:CC flags))
        ]) "test-asm.c":8)

I think we need to escape the asm string, giving something like:

(insn (parallel [
            (set (reg:DI ax [orig:89 msr ] [89])
      
          (asm_operands/v:DI ("rdtsc\n\tshl $32, %%rdx\n\n\tor %%rdx,
%0") ("=a") 0 []
                     []
                     [] "test
-asm.c":8))
            (clobber (reg:DI dx))
            (clobber
(reg:CCFP fpsr))
            (clobber (reg:CC flags))
        ]) "test
-asm.c":8)

We should probably edit the "orig" thing:
   [orig:89 msr ] [89]
to lose the regno, for consistency, giving something like:

(insn (parallel [
            (set (reg:DI ax [orig:msr])
               
 (asm_operands/v:DI ("rdtsc\n\tshl $32, %%rdx\n\n\tor %%rdx, %0")
("=a") 0 []
                     []
                     [] "test
-asm.c":8))
            (clobber (reg:DI dx))
            (clobber
(reg:CCFP fpsr))
            (clobber (reg:CC flags))
        ]) "test
-asm.c":8)

Does this look sane?

> One other thing in terms of format is the printout of CONST_INT - I 
> think it should suffice to have either decimal, or hex, but not
> really 
> both. The reader should maybe accept either.

OK, that will make things a little less verbose.

> I think all hosts have 64-bit HWI these days, so CONST_INT ought to 
> always stay valid through a roundtrip.
> 
> I may have missed it, but is there any kind of provision yet for 
> providing an "after" dump for what is expected after a pass is run? 
> Might be worth thinking about whether the reader could have a mode
> where 
> it matches internal RTL against an input.

Interesting idea.  Are you hoping for an exact match?  I'm a bit
nervous that this could over-specifier behavior, making test cases
brittle.

> > OK.  If so, do we need to print the regno for hard registers?  Or
> > should we just print the name for those, for consistency with
> > virtual
> > regs?  (i.e. have it be controlled by the same flag?)
> 
> Just the name should work, leaving only pseudos with numbers - that 
> ought to be reasonable. 

OK

> In the reader, when encountering a reg with a 
> number, just add FIRST_PSEUDO_REGISTER, and you should end up with 
> something that's consistent. Or maybe even dump the expected 
> FIRST_PSEUDO_REGISTER, and adjust for it in case the one we have at 
> run-time differs.

Another idea might be to give the pseudos names, so that all regs have
names: so that we'd have "pseudo-5", "pseudo-6", etc.

(given that 
#define FIRST_VIRTUAL_REGISTER	(FIRST_PSEUDO_REGISTER)
#define LAST_VIRTUAL_REGISTER		((FIRST_VIRTUAL_REGISTER)
+ 5)
)


> > > Does the C one have an advantage in terms of meaningful decls in
> > > MEM_ATTRs/SYMBOL_REFs?
> > 
> > Probably.
> 
> I think that might be the more promising path then.
> 
> 
> Bernd



More information about the Gcc-patches mailing list