public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <richard.guenther@gmail.com>
To: "Martin Liška" <mliska@suse.cz>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>, Jan Hubicka <hubicka@ucw.cz>
Subject: Re: [PATCH v2] Dump BB number when dumping a BB with label.
Date: Mon, 31 Jul 2017 08:50:00 -0000	[thread overview]
Message-ID: <CAFiYyc1_8Y40rV5uk=YLCvTDNrzgb_-uebfQ9fouq1-Zk+C0AQ@mail.gmail.com> (raw)
In-Reply-To: <a1fcc826-a41b-9ed7-b7bc-2e3c81ec35ba@suse.cz>

On Mon, Jul 31, 2017 at 8:43 AM, Martin Liška <mliska@suse.cz> wrote:
> On 07/28/2017 01:21 PM, Richard Biener wrote:
>> On Fri, Jul 28, 2017 at 12:52 PM, Martin Liška <mliska@suse.cz> wrote:
>>> On 07/28/2017 09:58 AM, Richard Biener wrote:
>>>> On Fri, Jul 28, 2017 at 9:50 AM, Martin Liška <mliska@suse.cz> wrote:
>>>>> On 07/28/2017 09:21 AM, Richard Biener wrote:
>>>>>> On Thu, Jul 27, 2017 at 4:24 PM, Martin Liška <mliska@suse.cz> wrote:
>>>>>>> Hi.
>>>>>>>
>>>>>>> Following simple patch adds support for dumping of BBs when it's a BB
>>>>>>> that contains a label. That makes it easier for debugging as one can
>>>>>>> find destination for an edge in dump file.
>>>>>>>
>>>>>>> Sample, before:
>>>>>>>
>>>>>>> foo (int a)
>>>>>>> {
>>>>>>>   int D.1821;
>>>>>>>   int _1;
>>>>>>>   int _4;
>>>>>>>   int _5;
>>>>>>>
>>>>>>>   <bb 2> [0.00%] [count: INV]:
>>>>>>>   switch (a_2(D)) <default: <L2> [INV] [count: INV], case 0: <L0> [INV] [count: INV], case 1: <L1> [INV] [count: INV]>
>>>>>>>
>>>>>>> <L0> [0.00%] [count: INV]:
>>>>>>>   a_3 = a_2(D) + 2;
>>>>>>>
>>>>>>> <L1> [0.00%] [count: INV]:
>>>>>>>   _4 = 2;
>>>>>>>   goto <bb 6> (<L3>); [INV] [count: INV]
>>>>>>>
>>>>>>> <L2> [0.00%] [count: INV]:
>>>>>>>   _5 = 123;
>>>>>>>
>>>>>>>   # _1 = PHI <_4(4), _5(5)>
>>>>>>> <L3> [0.00%] [count: INV]:
>>>>>>>   return _1;
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>> After:
>>>>>>>
>>>>>>> foo (int a)
>>>>>>> {
>>>>>>>   int D.1821;
>>>>>>>   int _1;
>>>>>>>   int _4;
>>>>>>>   int _5;
>>>>>>>
>>>>>>>   <bb 2> [0.00%] [count: INV]:
>>>>>>>   switch (a_2(D)) <default: <L2> [INV] [count: INV], case 0: <L0> [INV] [count: INV], case 1: <L1> [INV] [count: INV]>
>>>>>>>
>>>>>>> <L0> (<bb 3>) [0.00%] [count: INV]:
>>>>>>>   a_3 = a_2(D) + 2;
>>>>>>>
>>>>>>> <L1> (<bb 4>) [0.00%] [count: INV]:
>>>>>>>   _4 = 2;
>>>>>>>   goto <bb 6> (<L3>); [INV] [count: INV]
>>>>>>>
>>>>>>> <L2> (<bb 5>) [0.00%] [count: INV]:
>>>>>>>   _5 = 123;
>>>>>>>
>>>>>>>   # _1 = PHI <_4(4), _5(5)>
>>>>>>> <L3> (<bb 6>) [0.00%] [count: INV]:
>>>>>>>   return _1;
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>>>>>>>
>>>>>>> Thoughts?
>>>>>>
>>>>>> I think I prefer to always see
>>>>>>
>>>>>>   <bb 3> ....:
>>>>>>
>>>>>> and if there's a label just dump that as well, thus
>>>>>>
>>>>>>   <bb 3> ....:
>>>>>>   L0:
>>>>>>
>>>>>> I think that's how we dump the case with multiple labels.  And always use the
>>>>>> implicit bb N when dumping destinations (in gotos, switches, etc).
>>>>>>
>>>>>> That is, what we have now is IMHO premature prettifying losing BB
>>>>>> indices in the dumps
>>>>>> unnecessarily.
>>>>>>
>>>>>> Richard.
>>>>>
>>>>> Hi.
>>>>>
>>>>> I like your ideas, there's difference in between 7.1 and modified trunk:
>>>>>
>>>>> foo (int a)
>>>>> {
>>>>>   int D.1824;
>>>>>   int _1;
>>>>>   int _4;
>>>>>   int _6;
>>>>>
>>>>>   <bb 2> [0.00%] [count: INV]:
>>>>>   switch (a_2(D)) <default: <L2> [INV] [count: INV], case 0: <L0> [INV] [count: INV], case 1: <L1> [INV] [count: INV]>
>>>>>
>>>>> <L0> [0.00%] [count: INV]:
>>>>>   a_3 = a_2(D) + 2;
>>>>>
>>>>> <L1> [0.00%] [count: INV]:
>>>>>   _4 = 2;
>>>>>   goto <bb 8> (<L6>); [INV] [count: INV]
>>>>>
>>>>> <L2> [0.00%] [count: INV]:
>>>>>
>>>>>   <bb 6> [0.00%] [count: INV]:
>>>>>   a_5 = a_2(D) + 2;
>>>>>
>>>>> label_XXX [0.00%] [count: INV]:
>>>>> label_YYY [0.00%] [count: INV]:
>>>>>   _6 = 101;
>>>>>
>>>>>   # _1 = PHI <_4(4), _6(7)>
>>>>> <L6> [0.00%] [count: INV]:
>>>>>   return _1;
>>>>>
>>>>> }
>>>>>
>>>>> after:
>>>>>
>>>>> foo (int a)
>>>>> {
>>>>>   int D.1824;
>>>>>   int _1;
>>>>>   int _4;
>>>>>   int _6;
>>>>>
>>>>>   <bb 2> [0.00%] [count: INV]:
>>>>>   switch (a_2(D)) <default: <bb 5> [INV] [count: INV], case 0: <bb 3> [INV] [count: INV], case 1: <bb 4> [INV] [count: INV]>
>>>>>
>>>>>   <bb 3> [0.00%] [count: INV]:
>>>>> <L0>:
>>>>>   a_3 = a_2(D) + 2;
>>>>>
>>>>>   <bb 4> [0.00%] [count: INV]:
>>>>> <L1>:
>>>>>   _4 = 2;
>>>>>   goto <bb 8>; [INV] [count: INV]
>>>>>
>>>>>   <bb 5> [0.00%] [count: INV]:
>>>>> <L2>:
>>>>>
>>>>>   <bb 6> [0.00%] [count: INV]:
>>>>>   a_5 = a_2(D) + 2;
>>>>>
>>>>>   <bb 7> [0.00%] [count: INV]:
>>>>> label_XXX:
>>>>> label_YYY:
>>>>>   _6 = 101;
>>>>>
>>>>>   <bb 8> [0.00%] [count: INV]:
>>>>>   # _1 = PHI <_4(4), _6(7)>
>>>>> <L6>:
>>>>>   return _1;
>>>>>
>>>>> }
>>>>>
>>>>> Do you like it? What about indentation of labels, should I increase it or leave it?
>>>>
>>>> Leave it.
>>>>
>>>>> I guess there will be some tests that will need to be adjusted.
>>>>
>>>> I guess so.
>>>>
>>>> I think <L0>: and friends are all DECL_ARTIFICIAL -- maybe we can avoid dumping
>>>> them?  Hmm, I guess doing it like above, while it preserves BB numbering, does
>>>> reflect the actual IL a bit less so I guess I'd leave the <L0>s in
>>>> switches (those
>>>> have labels) and gotos if there's still the label args (not in case of
>>>> we are just
>>>> dumping CFG edges).
>>>
>>> Good, thus said there's how it will look like:
>>>
>>> $ cat /tmp/switch.c
>>> int c;
>>>
>>> int foo(int a)
>>> {
>>>   switch (a)
>>>   {
>>>   case 0:
>>>     a += 2;
>>>   case 1:
>>>     if (c)
>>>       goto label_XXX;
>>>     return 2;
>>>   default:
>>>     break;
>>>   }
>>>
>>>   a += 2;
>>>
>>> label_XXX:
>>> label_YYY:
>>>   return 99 + 2;
>>> }
>>>
>>> $ ./xgcc -B. /tmp/switch.c -fdump-tree-optimized=/dev/stdout
>>>
>>> ;; Function foo (foo, funcdef_no=0, decl_uid=1816, cgraph_uid=0, symbol_order=1)
>>>
>>> foo (int a)
>>> {
>>>   int D.1827;
>>>   int c.0_1;
>>>   int _2;
>>>   int _6;
>>>   int _8;
>>>
>>>   <bb 2> [0.00%] [count: INV]:
>>>   switch (a_3(D)) <default: <L4> [INV] [count: INV], case 0: <L0> [INV] [count: INV], case 1: <L1> [INV] [count: INV]>
>>>
>>>   <bb 3> [0.00%] [count: INV]:
>>> <L0>:
>>>   a_4 = a_3(D) + 2;
>>>
>>>   <bb 4> [0.00%] [count: INV]:
>>> <L1>:
>>>   c.0_1 = c;
>>>   if (c.0_1 != 0)
>>>     goto <bb 5>; [INV] [count: INV]
>>>   else
>>>     goto <bb 6>; [INV] [count: INV]
>>>
>>>   <bb 5> [0.00%] [count: INV]:
>>>   goto <bb 9>; [INV] [count: INV]
>>>
>>>   <bb 6> [0.00%] [count: INV]:
>>>   _6 = 2;
>>>   goto <bb 10>; [INV] [count: INV]
>>>
>>>   <bb 7> [0.00%] [count: INV]:
>>> <L4>:
>>>
>>>   <bb 8> [0.00%] [count: INV]:
>>>   a_7 = a_3(D) + 2;
>>>
>>>   <bb 9> [0.00%] [count: INV]:
>>> label_XXX:
>>> label_YYY:
>>>   _8 = 101;
>>>
>>>   <bb 10> [0.00%] [count: INV]:
>>>   # _2 = PHI <_6(6), _8(9)>
>>> <L8>:
>>>   return _2;
>>>
>>> }
>>>
>>>
>>> Note that edge bb_5->bb_9 is represented after gimplification by implicit edge, not by goto. But:
>>>
>>> ./xgcc -B. /tmp/switch.c -fdump-tree-lower=/dev/stdout
>>>
>>> ;; Function foo (foo, funcdef_no=0, decl_uid=1816, cgraph_uid=0, symbol_order=1)
>>>
>>> foo (int a)
>>> {
>>>   int D.1827;
>>>
>>>   switch (a) <default: <D.1821>, case 0: <D.1818>, case 1: <D.1819>>
>>>   <D.1818>:
>>>   a = a + 2;
>>>   <D.1819>:
>>>   c.0_1 = c;
>>>   if (c.0_1 != 0) goto <D.1825>; else goto <D.1826>;
>>>   <D.1825>:
>>>   goto label_XXX;
>>>   <D.1826>:
>>>   D.1827 = 2;
>>>   goto <D.1828>;
>>>   <D.1821>:
>>>   goto <D.1822>;
>>>   <D.1822>:
>>>   a = a + 2;
>>>   label_XXX:
>>>   label_YYY:
>>>   D.1827 = 101;
>>>   goto <D.1828>;
>>>   <D.1828>:
>>>   return D.1827;
>>> }
>>>
>>> There labels are dumped properly. If it's ok I'll start working on test-suite transition.
>>
>> Yes.  Looks good to me now.
>>
>> That said... if the fallout is very big we might consider switching to
>> -gimple style dumping
>> unconditionally?
>>
>> Richard.
>
> Hello.
>
> Sending second version of the patch. Eventually it shows that fallout for test suite was minimal.
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>
> Ready to be installed?

Ok.  Nice that it also simplifies code.

Thanks,
Richard.

> Martin
>
>>
>>> Martin
>>>
>>>>
>>>> Richard.
>>>>
>>>>> Martin
>>>>>
>>>>>>
>>>>>>> Martin
>>>>>>>
>>>>>>> gcc/testsuite/ChangeLog:
>>>>>>>
>>>>>>> 2017-07-27  Martin Liska  <mliska@suse.cz>
>>>>>>>
>>>>>>>         * gcc.dg/builtin-unreachable-6.c: Update scanned pattern.
>>>>>>>         * gcc.dg/tree-ssa/attr-hotcold-2.c: Likewise.
>>>>>>>         * gcc.dg/tree-ssa/ssa-ccp-18.c: Likewise.
>>>>>>>
>>>>>>> gcc/ChangeLog:
>>>>>>>
>>>>>>> 2017-07-27  Martin Liska  <mliska@suse.cz>
>>>>>>>
>>>>>>>         * gimple-pretty-print.c (dump_gimple_label): Dump BB number.
>>>>>>> ---
>>>>>>>  gcc/gimple-pretty-print.c                      | 6 +++++-
>>>>>>>  gcc/testsuite/gcc.dg/builtin-unreachable-6.c   | 2 +-
>>>>>>>  gcc/testsuite/gcc.dg/tree-ssa/attr-hotcold-2.c | 4 ++--
>>>>>>>  gcc/testsuite/gcc.dg/tree-ssa/ssa-ccp-18.c     | 3 +--
>>>>>>>  4 files changed, 9 insertions(+), 6 deletions(-)
>>>>>>>
>>>>>>>
>>>>>
>>>
>

  reply	other threads:[~2017-07-31  8:50 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-27 14:24 [PATCH] " Martin Liška
2017-07-28  7:21 ` Richard Biener
2017-07-28  7:50   ` Martin Liška
2017-07-28  7:58     ` Richard Biener
2017-07-28 10:53       ` Martin Liška
2017-07-28 11:21         ` Richard Biener
2017-07-31  6:44           ` [PATCH v2] " Martin Liška
2017-07-31  8:50             ` Richard Biener [this message]
2017-07-31  8:53               ` Martin Liška

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='CAFiYyc1_8Y40rV5uk=YLCvTDNrzgb_-uebfQ9fouq1-Zk+C0AQ@mail.gmail.com' \
    --to=richard.guenther@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hubicka@ucw.cz \
    --cc=mliska@suse.cz \
    /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).