linux-sparse.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christopher Li <sparse@chrisli.org>
To: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Cc: Linux-Sparse <linux-sparse@vger.kernel.org>
Subject: Re: [PATCH 1/5] do not corrupt ptrlist while killing unreachable BBs
Date: Sun, 9 Jul 2017 07:44:46 -0700	[thread overview]
Message-ID: <CANeU7Q=GHJgpr2sST3JP3=Dz1OEtae5j2Zeg0xmT1Toc-x1AzQ@mail.gmail.com> (raw)
In-Reply-To: <20170709102637.6pakvvwfduzulatl@ltop.local>

On Sun, Jul 9, 2017 at 3:26 AM, Luc Van Oostenryck
<luc.vanoostenryck@gmail.com> wrote:
>> diff --git a/flow.c b/flow.c
>> index c7161d4..5d2f15a 100644
>> --- a/flow.c
>> +++ b/flow.c
>> @@ -841,7 +841,7 @@ void kill_unreachable_bbs(struct entrypoint *ep)
>>   } END_FOR_EACH_PTR(bb);
>>   PACK_PTR_LIST(&ep->bbs);
>>
>> - repeat_phase &= ~REPEAT_CFG_CLEANUP;
>> + repeat_phase |=  REPEAT_CSE ;
>
> It would be good to add a comment for why the '|= REPEAT_CSE' is needed here.
OK. I will update the patch. Basically removing unreachable dead code will
impact the us


> And not removing the REPEAT_CFG_CLEANUP is an error IMO.
> At the end of the function the CFG *is* clean. If you don't
> clear it here, then what is its meaning?
It is an error as concept or it is an error the program will do wrong
things?

I want to turn REPEAT_CFG_CLEANUP usage pattern similar
to REPEAT_SYMBOL_CLEANUP. Take the a look at

if (repeat_phase & REPEAT_SYMBOL_CLEANUP)
simplify_memops(ep);

The simplify_memops does not clear the REPEAT_SYMBOL_CLEANUP
either. It was clear at the very beginning of the cse repeat loop:

repeat:
repeat_phase = 0;

I just want to be consistent with other usage of the similar flags.

It is also a reflection of my review feedback when you submit the
patch back then. One of the comment I give was that I want to
avoid calling "kill unreachable bb" multiple time within one "ep->bbs"
pass. You said there is no simple way to do it. This patch is actually
what I want back then.

I think when you introduce REPEAT_CFG_CLEANUP you have
different usage in mind. I found the flag clean at beginning of the
CSE loop is conceptually clean as well, it is simpler. The flag
is just a request, it can set more than one times. The action is
perform only once at one CSE pass.

Chris

  reply	other threads:[~2017-07-09 14:44 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-06 19:19 [PATCH 0/5] fixes for rare crashes Luc Van Oostenryck
2017-07-06 19:19 ` [PATCH 1/5] do not corrupt ptrlist while killing unreachable BBs Luc Van Oostenryck
2017-07-07  0:40   ` Christopher Li
2017-07-07  1:18     ` Christopher Li
2017-07-07  1:35       ` Linus Torvalds
2017-07-07  5:15         ` Christopher Li
2017-07-07  8:28           ` Luc Van Oostenryck
2017-07-07  9:06             ` Christopher Li
2017-07-07  9:30               ` Luc Van Oostenryck
2017-07-07  9:54                 ` Christopher Li
2017-07-07 13:18               ` Dibyendu Majumdar
2017-07-07 13:25                 ` Luc Van Oostenryck
2017-07-07 13:29                   ` Dibyendu Majumdar
2017-07-07 13:47                     ` Luc Van Oostenryck
2017-07-08 15:43                       ` Christopher Li
2017-07-07  9:52             ` Luc Van Oostenryck
2017-07-07  6:07         ` Christopher Li
2017-07-07  5:44       ` Luc Van Oostenryck
2017-07-07  6:02         ` Christopher Li
2017-07-07  6:10           ` Luc Van Oostenryck
2017-07-07  6:27             ` Christopher Li
2017-07-07  7:30               ` Luc Van Oostenryck
2017-07-07  9:19           ` Dibyendu Majumdar
2017-07-07  9:26             ` Dibyendu Majumdar
2017-07-07  9:38               ` Luc Van Oostenryck
2017-07-07  9:41                 ` Dibyendu Majumdar
2017-07-07  9:58                   ` Christopher Li
2017-07-07 10:08                     ` Dibyendu Majumdar
2017-07-07 12:54                       ` Christopher Li
2017-07-07 13:01                         ` Dibyendu Majumdar
2017-07-07  9:44             ` Christopher Li
2017-07-07  9:46               ` Dibyendu Majumdar
2017-07-07 10:00                 ` Luc Van Oostenryck
2017-07-07  6:04       ` Luc Van Oostenryck
2017-07-07  6:18         ` Christopher Li
2017-07-07  7:11           ` Luc Van Oostenryck
2017-07-07  8:25             ` Christopher Li
2017-07-07  8:32               ` Luc Van Oostenryck
2017-07-09  9:07   ` Christopher Li
2017-07-09 10:26     ` Luc Van Oostenryck
2017-07-09 14:44       ` Christopher Li [this message]
2017-07-09 16:11         ` Luc Van Oostenryck
2017-07-06 19:19 ` [PATCH 2/5] avoid crash when ep->active is NULL Luc Van Oostenryck
2017-07-19 22:20   ` Luc Van Oostenryck
2017-07-20  4:37     ` Christopher Li
2017-07-06 19:19 ` [PATCH 3/5] avoid crash in rewrite_branch() Luc Van Oostenryck
2017-07-19 22:21   ` Luc Van Oostenryck
2017-07-06 19:19 ` [PATCH 4/5] avoid some crashes in add_dominators() Luc Van Oostenryck
2017-07-19 22:22   ` Luc Van Oostenryck
2017-07-06 19:19 ` [PATCH 5/5] avoid crash with sym->bb_target == NULL Luc Van Oostenryck
2017-07-19 22:23   ` Luc Van Oostenryck
2017-07-20 10:57   ` Christopher Li
2017-07-29 12:30     ` Luc Van Oostenryck
2017-07-29 12:49       ` Christopher Li
2017-07-06 19:50 ` [PATCH 0/5] fixes for rare crashes Christopher Li

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='CANeU7Q=GHJgpr2sST3JP3=Dz1OEtae5j2Zeg0xmT1Toc-x1AzQ@mail.gmail.com' \
    --to=sparse@chrisli.org \
    --cc=linux-sparse@vger.kernel.org \
    --cc=luc.vanoostenryck@gmail.com \
    /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 NNTP newsgroup(s).