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
next prev parent 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).