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