public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: David Malcolm <dmalcolm@redhat.com>
To: Bernd Schmidt <bschmidt@redhat.com>, gcc-patches@gcc.gnu.org
Subject: Re: RTL frontend input format again (was Re: [PATCH 15/16] RTL frontend (rtl1), on top of dump reader)
Date: Fri, 07 Oct 2016 18:08:00 -0000	[thread overview]
Message-ID: <1475863702.30303.79.camel@redhat.com> (raw)
In-Reply-To: <0f83ea7f-136b-0b66-9068-f693e7b2f8d9@redhat.com>

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

  reply	other threads:[~2016-10-07 18:08 UTC|newest]

Thread overview: 96+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-05 15:44 [PATCH 00/16] RTL frontend (v3) David Malcolm
2016-10-05 15:44 ` [PATCH 11/16] df selftests (v3) David Malcolm
2016-10-05 15:44 ` [PATCH 01/16] read-md.c: Add various cleanups to ~rtx_reader David Malcolm
2016-10-05 15:51   ` Bernd Schmidt
2016-10-11 15:15     ` David Malcolm
2016-10-12 21:57       ` Richard Sandiford
2016-10-14 17:45         ` [PATCH] read-md.c: Move various state to within class rtx_reader David Malcolm
2016-10-17 11:05           ` Bernd Schmidt
2016-10-17 11:37           ` Richard Sandiford
2016-10-17 16:27             ` [PATCH] read-md.c: Move various state to within class rtx_reader (v3) David Malcolm
2016-10-17 20:23               ` Richard Sandiford
2016-10-05 15:44 ` [PATCH 08/16] (partially-approved): Introduce selftest::locate_file David Malcolm
2016-10-05 16:10   ` Bernd Schmidt
2016-10-05 15:44 ` [PATCH 07/16] read-md: add some helper functions David Malcolm
2016-10-05 15:57   ` Bernd Schmidt
2016-10-05 15:45 ` [PATCH 16/16] Add "__RTL" to cc1 David Malcolm
2016-10-05 16:10   ` Joseph Myers
2016-10-07 15:27     ` [PATCH] Add "__RTL" to cc1 (v2) David Malcolm
2016-10-13 13:49       ` Richard Biener
2016-10-13 13:52         ` Bernd Schmidt
2016-10-14  9:33           ` Richard Biener
2016-10-14  9:48             ` Bernd Schmidt
2016-10-14  9:50               ` Richard Biener
2016-10-14 19:25             ` David Malcolm
2016-10-14 19:27               ` Bernd Schmidt
2016-10-14 19:35                 ` David Malcolm
2016-10-14 19:23         ` David Malcolm
2016-10-05 15:45 ` [PATCH 03/16] (approved) selftest.h: add temp_override fixture David Malcolm
2016-10-05 15:45 ` [PATCH 14/16] RTL interpreter (work-in-progress) David Malcolm
2016-10-05 15:45 ` [PATCH 09/16] Split class rtx_reader into base_rtx_reader vs rtx_reader David Malcolm
2016-10-11 15:53   ` Bernd Schmidt
2016-10-18 20:30     ` David Malcolm
2016-10-19 14:45       ` Bernd Schmidt
2016-10-20 19:14         ` Richard Sandiford
2016-10-05 15:45 ` [PATCH 06/16] Introduce emit_status::ensure_regno_capacity David Malcolm
2016-10-05 15:55   ` Bernd Schmidt
2016-10-05 15:55   ` Bernd Schmidt
2016-11-18 20:47     ` [PATCH] Introduce emit_status::ensure_regno_capacity (v5) David Malcolm
2016-11-22 13:34       ` Bernd Schmidt
2016-10-05 15:45 ` [PATCH 04/16] (approved) Expose forcibly_ggc_collect and run it after all selftests David Malcolm
2016-10-05 15:45 ` [PATCH 10/16] Introduce class function_reader (v3) David Malcolm
2016-10-05 16:00   ` Bernd Schmidt
2016-10-07 13:44     ` David Malcolm
2016-10-10 18:53       ` Richard Sandiford
2016-10-05 15:45 ` [PATCH 05/16] Introduce rtl_data::init_stack_alignment David Malcolm
2016-10-05 15:52   ` Bernd Schmidt
2016-10-05 15:45 ` [PATCH 15/16] RTL frontend (rtl1), on top of dump reader David Malcolm
2016-10-06 13:30   ` Bernd Schmidt
2016-10-06 19:53     ` RTL frontend input format again (was Re: [PATCH 15/16] RTL frontend (rtl1), on top of dump reader) David Malcolm
2016-10-06 19:59       ` David Malcolm
2016-10-07 10:38       ` Bernd Schmidt
2016-10-07 13:27         ` David Malcolm
2016-10-07 13:58           ` Bernd Schmidt
2016-10-07 18:08             ` David Malcolm [this message]
2016-10-12 10:45             ` [PATCH] print_rtx_function: integrate dumping of the CFG into the insn chain David Malcolm
2016-10-12 10:50               ` Bernd Schmidt
2016-10-12 17:17             ` [PATCH] Add a "compact" mode to print_rtx_function David Malcolm
2016-10-12 17:31               ` Bernd Schmidt
2016-10-12 20:06                 ` [PATCH] (v2) " David Malcolm
2016-10-13 10:21                   ` Bernd Schmidt
2016-10-13 15:22                     ` [PATCH] Omit INSN_LOCATION from compact dumps David Malcolm
2016-10-13 15:50                       ` Bernd Schmidt
2016-11-22 13:18                   ` [PATCH] (v2) Add a "compact" mode to print_rtx_function Dominik Vogt
2016-11-22 13:32                     ` Bernd Schmidt
2016-11-22 13:37                       ` Jakub Jelinek
2016-11-22 14:25                         ` David Malcolm
2016-11-22 14:39                           ` Dominik Vogt
2016-11-22 14:38                         ` Bernd Schmidt
2016-11-22 14:45                           ` Jakub Jelinek
2016-11-22 15:38                             ` David Malcolm
2016-11-25 16:37                               ` Dominik Vogt
2016-12-01 10:13                               ` [PING] " Dominik Vogt
2016-12-01 12:28                                 ` Bernd Schmidt
2016-12-02 12:36                                   ` Andreas Krebbel
2016-10-12 20:33                 ` [PATCH] Tweaks " David Malcolm
2016-10-13 10:24                   ` Bernd Schmidt
2016-10-13 14:08                     ` David Malcolm
2016-10-13 14:18                       ` Bernd Schmidt
2016-10-14 19:41                         ` [PATCH] (v2) " David Malcolm
2016-10-14 20:07                           ` Bernd Schmidt
2016-10-19 14:36             ` RTL frontend input format again (was Re: [PATCH 15/16] RTL frontend (rtl1), on top of dump reader) David Malcolm
2016-10-19 14:42               ` Bernd Schmidt
2016-10-19 17:19                 ` David Malcolm
2016-10-19 17:22                   ` Bernd Schmidt
2016-10-19 17:54                     ` David Malcolm
2016-10-20 13:55     ` INSN_UIDs " David Malcolm
2016-10-20 14:11       ` Bernd Schmidt
2016-10-20 14:20         ` David Malcolm
2016-10-20 14:22           ` Bernd Schmidt
2016-10-26 18:19         ` [PATCH] Show INSN_UIDs in compact mode David Malcolm
2016-10-26 18:20           ` Bernd Schmidt
2016-10-06 15:24   ` [PATCH 15/16] RTL frontend (rtl1), on top of dump reader Bernd Schmidt
2016-10-07 16:22     ` [PATCH] RTL frontend (rtl1), on top of dump reader (v4) David Malcolm
2016-10-05 15:45 ` [PATCH 12/16] combine.c selftests (v2) David Malcolm
2016-10-05 15:45 ` [PATCH 02/16] (approved) Add selftest::read_file David Malcolm
2016-10-05 15:45 ` [PATCH 13/16] cse.c selftests David Malcolm

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1475863702.30303.79.camel@redhat.com \
    --to=dmalcolm@redhat.com \
    --cc=bschmidt@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).