From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.ispras.ru (mail.ispras.ru [83.149.199.84]) by sourceware.org (Postfix) with ESMTPS id D4F623858C27 for ; Mon, 3 Jan 2022 16:35:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D4F623858C27 Received: from [10.10.3.121] (unknown [10.10.3.121]) by mail.ispras.ru (Postfix) with ESMTPS id CFC6940D403E; Mon, 3 Jan 2022 16:35:17 +0000 (UTC) Date: Mon, 3 Jan 2022 19:35:17 +0300 (MSK) From: Alexander Monakov To: Richard Biener cc: =?KOI8-R?B?4czFy9PFyiDu1dLN1cjBzcXUz9c=?= , GCC Patches Subject: Re: [RFC PATCH] tree-ssa-sink: do not sink to in front of setjmp In-Reply-To: Message-ID: References: <4493B84A-DB6D-468B-86BF-DA5383D8CFE4@gmail.com> <794111d4-a64c-17e5-a4fe-f96e5182ee1@ispras.ru> <9252c923-c86a-7c98-ec5f-97410fbca8ed@ispras.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2022 16:35:28 -0000 On Mon, 3 Jan 2022, Richard Biener wrote: > > @@ -5674,6 +5675,14 @@ gimple_verify_flow_info (void) > > err = 1; > > } > > > > + if (prev_stmt && stmt_starts_bb_p (stmt, prev_stmt)) > > stmt_starts_bb_p is really a helper used during CFG build, I'd rather > test explicitely for a GIMPLE call with ECF_RETURNS_TWICE, or maybe, > verify that iff a block has abnormal predecessors it starts with such > a call (because IIRC we in some cases elide abnormal edges and then > it's OK to move "down" the calls). So yes, if a block has abnormal preds > it should start with a ECF_RETURNS_TWICE call, I think we cannot > verify the reverse reliably - abnormal edges cannot easily be re-built > in late stages (it's a bug that we do so during RTL expansion). Thanks, I could rewrite the patch along those lines, but I'm not sure where this is going: the ~100 extra FAILs will still be there. What would the next steps be for this patch and the initial tree-ssa-sink patch? Alexander