From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 45907 invoked by alias); 20 Nov 2018 07:59:22 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 45883 invoked by uid 89); 20 Nov 2018 07:59:22 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=naked, mystery X-HELO: smtp.eu.adacore.com Received: from mel.act-europe.fr (HELO smtp.eu.adacore.com) (194.98.77.210) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 20 Nov 2018 07:59:20 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 1CDE2813A0; Tue, 20 Nov 2018 08:59:18 +0100 (CET) Received: from smtp.eu.adacore.com ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8ZUGDVnaioY; Tue, 20 Nov 2018 08:59:18 +0100 (CET) Received: from polaris.localnet (bon31-6-88-161-99-133.fbx.proxad.net [88.161.99.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.eu.adacore.com (Postfix) with ESMTPSA id 87F0381387; Tue, 20 Nov 2018 08:59:17 +0100 (CET) From: Eric Botcazou To: Uros Bizjak Cc: gcc-patches@gcc.gnu.org, Jeff Law Subject: Re: [PATCH, middle-end]: Fix PR 88070, ICE in create_pre_exit, at mode-switching.c:438 Date: Tue, 20 Nov 2018 07:59:00 -0000 Message-ID: <2557077.nCGLyblqtb@polaris> In-Reply-To: References: <2354868.li0E72aPaB@polaris> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-SW-Source: 2018-11/txt/msg01681.txt.bz2 > The blockage was introduced as a fix for PR14381 [1] in r79265 [2]. > Later, the blockage was moved after return label as a fix for PR25176 > [3] in r107871 [4]. > > After that, r122626 [5] moves the blockage after the label for the > naked return from the function. Relevant posts from gcc-patches@ ML > are at [6], [7]. However, in the posts, there are no concrete > examples, how scheduler moves instructions from different BB around > blockage insn, the posts just show that there is a jump around > blockage when __builtin_return is used. I was under impression that > scheduler is unable to move instructions over BB boundaries. The scheduler works on extended basic blocks. The [7] post gives a rather convincing explanation and there is a C++ testcase under PR rtl-opt/14381. > A mystery is the tree-ssa merge [8] that copies back the hunk, moved > in r122626 [5] to its original position. From this revision onwards, > we emit two blockages. It's the dataflow merge, not the tree-ssa merge. The additional blockage might be needed for DF. Given that the current PR is totally artificial, I think that we need to be quite conservative and only do something on mainline. And even there I'd be rather conservative and remove the kludge only for targets that emit unwind information in the epilogue (among which there is x86 I presume). -- Eric Botcazou